How to Make Product Management for Enterprise Systems Work [Mind the Product]

I love building enterprise systems, because you get to work with your customers/users every day and literally see their lives change as you release new features. In my case, at Zalando, these are systems for fashion buying, supply chain management, inventory management and procure-to-pay processes (e.g. paying our suppliers for merchandise we bought from them). But building good enterprise systems is prone to failure, as author and product consultant Sam McAfee has recently pointed out.

While most product management articles and blogs talk about product management for consumer-facing or enterprise SaaS products, I’ve found that many of the methods and insights discussed in these can also be applied to developing enterprise software to be used by your company’s internal users.

This article is an attempt to share some of the lessons we’ve learned at Zalando. We’re one of Europe’s leading online fashion platforms and in the past few years we’ve moved from a more traditional “internal IT setup” to a product-driven culture that develops industry-leading bespoke enterprise solutions.

Allow Your Enterprise Systems Teams to own a Problem

As with any product decision, the first step to finding the best solution is to own and understand the problem. In a traditional internal IT setup, someone from the “business side” has an idea of what to improve. Frequently, this idea includes a detailed description of the solution they would like “IT to implement”.

This is where the problems usually start. Many of these ideas create only limited value, and together they do not form a coherent product vision. And this is not a surprise; these colleagues know their business but they are not trained product managers. Unfortunately, the “product manager” (often called “business analyst” in such a setup) does not have the authority to push back on such requirements, but rather focuses on translating the business requirements into a detailed design that software engineers can then implement.

At Zalando, we changed this. We created multi-disciplinary teams that own specific business KPIs, together with their internal users. For example, our Competence Centre Inventory Management co-owns merchandise availability (an important KPI for every retailer) with the merchandise planners. The team consists of software engineers, product managers, product designers, controllers and analysts, who work very closely with our 250 merchandise planners (their internal users) and our 1,500-plus suppliers to identify the biggest levers to improve merchandise availability (and related KPIs). Some of these levers may require system improvements, some may not. They are free to decide what to work on next. They are also free to decide what systems to build in-house and where to leverage external solutions. They just need to ensure that the KPIs they co-own improve; and their progress is reviewed each quarter.

Bridge the Gap Between “Tech” and “Business”

The above setup made it even more important for us to break down functional silos, more specifically between commercial teams (i.e. “the business”) and tech teams (engineers, product managers). This was a big challenge for us. When we started, our commercial teams had never heard of agile or MVPs – and often just saw “MVP” as an excuse to cut down on the features they wanted, or “agile” as an excuse for not being able to commit to release dates. Similarly, our tech teams did not understand the main business decisions and the need for planning ahead. For example, when your business grows by 20-25% a year, knowing whether a key problem, one that creates a lot of manual effort, will be solved in six months or not, has significant implications on how many people you need to start hiring today. Similarly, when you plan a new business line launch (such as Beauty as a new category on Zalando), and you need to prepare a big marketing campaign and buy the relevant merchandise, all to go live at the start of a new season in nine months from now, you need some form of a commitment that the required system functionality will be available by then. We found the tech team would reject deadlines, as in their view, they contradicted an agile approach. It literally required us to bring two different worlds together.

How did we go about this? From an organisational standpoint, we fully merged the “business” with the “IT” teams (we used the terminology “tech is everywhere”). We now no longer have one big monolithic IT organization, but have formed smaller units, where business and tech teams report into the same senior leaders. At the same time, we invested a lot into strengthening the overall tech community through the creation of topic-specific guilds or interest groups, and other means, such as cross-team tech talks. We also invested in educating our commercial leaders in basic tech concepts, such as agile development, MVPs and the importance of not building up technical debt.

At a more operational level, we aim for all colleagues in our Enterprise Systems Teams (engineers, product designers, analysts, product managers) to take internships with their users regularly. This greatly helps to build a network and increases understanding of the business problems. We’ve built very active key user communities around all our systems, and use these communities to help us regularly align our feature backlog and priorities, usually monthly. We also ensure that users are always present in sprint reviews. In addition, we regularly organise informal exchanges across disciplines through random lunches and other events.

Recruit and Train the Right Product Managers

You may think this is all obvious, and you are right. However, recruiting and training the right kind of product manager for this kind of internal role is not straightforward, and I would argue even more challenging than recruiting and training product managers for other product management roles.

First, they need to be interested in redesigning and improving internal business processes and KPIs, a skill set and interest not every product manager brings. Second, they need to be great at managing change. When you build consumer-facing applications, the consumer either gets it or they will leave. With internal systems (and a captive audience), you can achieve more impact when you combine a system change with a process change, i.e. a change of “how we do things” (but this necessarily requires seeking and achieving buy-in from many stakeholders). This means that product managers for in-house enterprise systems will spend a lot of time with users, taking them along on the journey, running system training, and getting their users’ buy-in for the new solution.

Finally, our product managers need to make make-or-buy decisions and switch between developing a system in-house as part of an agile team and implementing an external solution alongside a systems integrator. Traditionally, these two are different roles with different skill sets. At Zalando, we want our product managers to own the problem and solve it in the best way possible, and they can only do this if they know how to use both internal and external solutions to solve that problem.

Of course, each of our product managers also needs to have full command of the main product management methodologies to discover, define, design, and deliver the right solutions for our users and problems. To do this, we regularly work with tools, such as press releases, pre-mortems, user story maps, design sprints (which we modified slightly), MVPs, and different ways to prioritize problems and solutions.

So where do we find these unique product managers? Well, there (still) seems to be only a small number of product managers out there who bring the full skill set we are looking for. Therefore, we either recruit people from a business team and teach them product management, or recruit (consumer-facing) product managers and enable them to learn the additional skills required. Luckily, by now we have quite a large product management community where colleagues can exchange best practices and help each other. If you are starting from scratch, I suggest you do what we did a few years ago: get a handful a smart people with different profiles and have them learn from each other, supported by a more formal product management curriculum.

We’re Still Learning

Of course, I could go into much more detail, but I’ll leave it here for now. I would love to hear any comments from the in-house systems product community out there. If you have any learnings to share, please also write a post; we are still just getting started!

The post How to Make Product Management for Enterprise Systems Work appeared first on Mind the Product.

Source: Mind the Product https://www.mindtheproduct.com/2018/04/make-product-management-enterprise-systems-work/