Does product management need a process?

A question that is frequently popping in my mind, discussed it with many of my colleagues and friends, and have seen organizations answering this question differently: Does product management need an established process that everyone follows? or is it a set of guidelines and following common sense?

To answer this question, let me go back to basics a little bit and ask: what is product management really about? it is about an idea that solves an immediate need (and possibly some other future needs) to well identified customer group(s)/segment(s) in a scalable and sustainable way, and how one can start by that idea and take it to market and grow it, hopefully, forever.

So, what does one need to take an idea to market?

1. Define that idea really well, define who would be the users, what their immediate (and future) need is, and how this idea will contribute to fulfill their need; that will need some market and user research to establish some hypotheses about the user needs, market size, differentiators from competition, etc...
2. Expand on the solution space, start experimenting and validating one's hypotheses with different ways of usability tests, making sure that these experiments are as cheap as possible, in terms of cost as well as impact on product perceived image
3. Define the minimum product that can be built to prove that the need will be fulfilled and that the identified user group(s)/segment(s) will get value out of it - AKA define the Minimum Valuable Product (MVP)
4. Develop the MVP, test it as much as one can with actual users
5. Launch the MVP, gather feedback and measure to get some useful analytics
6. Repeat the process to develop additional increments and provide users with additional value

Sounds like a good, straightforward and well established process, right?

Yes, and one can detail this process and use different tools to automate and track it (Been there, done that), and...

Also no; although it does look like a pretty process, but life doesn't always go as planned, let me give some examples:

• In Business-to-Business (B2B) world, access to potential customers to test your hypotheses with can be extremely limited, and impossible some other times as early exposure might be risky when it comes to competition; in these cases, one might develop the MVP directly based on market research and gut feeling, with no actual users research at all, close to what Slack did when they launched their MVP
• In Business-to-Consumer (B2C) world, sometimes an experiment might be very costly, imagine introducing a new smart phone to the market, it will need a massive cost of research and development to get a prototype with a real differentiator to the market; in this case, the process becomes completely different than the one above

For such reasons, the process is different from an organization to another, and sometimes from a business line to another within the same organization; even some products within the same business line need a different version of that process. And although many Software as a Service (SaaS) solutions tried to tackle this by being as flexible as possible in how one can define product management processes, I've seen these flexible processes needing changes every now and then, and hence failing at measuring how consistent and productive these processes are.

The other approach is to look at product management as a set of guidelines, and that is as simple as translating the above process to the "why" behind each of the steps; in other words:

• Define the idea really well, and document it
• When building hypotheses, rely on data and research insights as much as possible
• Whenever possible, test with actual users, and test everything: ideas, understanding of needs, solutions, prototypes, and every increment
• Fail fast... and cheap
• Do not try to build the full product at once, identify the minimum that can be built at a minimum cost
• Identify risks early on, and make sure every stakeholder is onboard

Looking at these guidelines, product management now seems more like a case rather than a process, where one knows the beginning and the destination, but there is no one path to reach that destination; a continuously evolving document, like an insurance claim, one only knows the next step by the current inputs and given context following a set of guidelines, rules and checklists.

Now, moving from the fancy cloud of theories to the land of reality, is this applicable for a scaling team? especially in large organizations with multiple products and lines of businesses? Surprisingly yes, with some guidance and asking the right questions, a team can become very good at leading a non-process or a common-sense-based approach, and if they do, they will become a team that will make one very proud.

However, this still does not work with every team either; an important aspect here is how experienced the team is, if the product team population has more people walking their first steps into product management, it might be wiser to have some processes in place at first, and make sure that the senior members of the team are guiding the new ones so they know when the process needs to be broken and why, and what the guidelines are if they need to break them. By time, the new ones will know that the process was there just to get them started, and they will follow the seniors' steps to the common-sense approach.

Happy to hear your feedback, what you tried, what worked for you and what didn't; feel free to comment or DM me.