How are tech products built? What is the process? How does product management work these days? Here is my way.
Let’s start from the 10’000ft view.
A company interacts with a market. It provides some value to the market through the means of a product, and in return can extract some value (money, data, attention etc.).
While that is simple, it is certainly not easy. There are many possible paths, many ways to provide value, many decision to be made.
To make sure a company and product team do take decisions in alignment, it needs direction. Once the direction is known, the teams need to discover possible levers and learn which ones work for the user and the business. Once it’s clear what works, teams need to decide which solutions to deliver to solve for the concrete needs of users.
A good product process covers all three parts: direction, discovery, delivery. Let’s look at each of these in more detail.
Direction
Setting the context the teams operate in is the job of leaders. It starts at the top with founders, board and the CEO. Nevertheless, all leaders in product need to create and communicate the context their teams work in. I think of direction in 3Ps: Perspective, Plan, Priorities.
Perspective
Leaders need to provide a perspective, a vision of the future (of the product) we are building. It includes an ambition, a world-view. It is an opinion, an angle on a problem. It includes a concrete goal of how to make the world better.
Plan
A plan, more often referred to as a Product Strategy, defines where we play and how we win. It describes how we intend to make our vision a reality. It supports our perspective and makes clear which bets we are making.
Priorities
To complete the context the teams need, we also need to make sure the sequence in which we tackle Product Opportunities that support our strategic bets is clear. We make explicit how are going to reduce the risk of our plan. With priorities we also make clear to everyone what is important, where to focus the attention.
Discovery
The goal of discovery is to reduce uncertainty. Once we are confident that a solution is likely to work, it is ready for Delivery. In other words, Discovery is about finding the right thing to do next. Discovery is a learning process.
Product discovery is the fun part. The most important part. The part where you will fail a lot and occasionally find the gold nugget in all the dirt. In my view it consists of collaborating with leadership to clarify where you are going and what the business needs, and collaborating with customers to understand their struggles and find solutions that work for them.
I use the acronym OOPS to describe the four components of discovery that need work: Opportunity, Outcomes, Problem-space, Solution-space.
COLLABORATION WITH LEADERSHIP
Here are the simple questions I try to answer before doing anything else. They ground me in reality and make the context clear. Thinking about the metrics to measure success will be harder than you think. Don’t skip it.
Opportunity
- What are we trying to achieve?
- Why is this important?
- Based on which insight?
- For whom is this? (target audience)
Outcomes
- Qualitative:
- What will success look like? (write a customer letter for example)
- Quantitative:
- How to measure success?
- How to ring-fence? (control metrics)
- How to measure progress?
COLLABORATION WITH CUSTOMER
Once I dive into an opportunity the next step will be to understand the problem really really well. From all angles, with data, with your heart. Empathise with the user, talk to them, watch them, dissect their behaviour, their emotions, their motivations. Really understand the struggle. Only then you’ll be able to judge a good solution from a bad one (you should still test it). Here are the questions I ask.
Problem-space
- Do we understand the user’s needs?
- How do we break this down into parts/sub-jobs? (where is the value?)
- What impacts (our) outcomes most?
Solution-space
- What is the smallest effective changes shippable (SECS)?
- How can we best test this solution?
- Shall we keep, iterate, improve, pivot, drop the solution?
Delivery
In Delivery we bring solutions to production, with all the bells and whistles. Delivery is doing the things right. Delivery is a production process.
No more prototypes or MVPs. This is the real deal. Delivery means shipping stable, production-grade, maintainable, high quality software. This is a no-crap zone. It will fall on our feet in the future if we ignore this. It will cost more to fix in the future than getting it right today. You were warned.
That said, this is the part most people identify with. This is where engineers thrive, where QA happens, where DevOps is important – we are working on the product users will use. I am obviously omitting many details of the engineering process (this doesn’t make them less important), as we are focused on the product process here.
For a product to be run successfully here, there are two things to be done: project management, analysing results. I keep these in mind with the acronym “PR” (as in “pull request” – what engineers do to integrate their code).
Produce
It’s time to organise work and make things happen. The product team needs to ship small increments as efficiently as possible. There will be some micro-prioritisation needed in this execution. However, it’s mostly about finding the effective order of operation, as we have already previously defined that this item is important (cf. Priorities and Problem-space). In my experience, much of this can be handled by engineering and people self-managing their work.
Results
Shipping things is great. Following up on the results is often overlooked. Yet, it’s a simple question to ask: did the feature achieve the desired outcomes?
We need to measure, analyse and monitor how the shipped item is doing in production. How users are interacting with it. And then we need to take a decision: will we improve on it, fix it, leave it as is or even kill it?
tl;dr
An effective product process will cover direction (knowing the purpose and plan of attack), discovery (learning what works) and delivery (building great software). There are many incarnations of the process and many frameworks can be used within each part. It’s not about the tools. It’s a system that works as a whole.
To remember the system, remember the acronyms: 3P-OOPS-PR.