Product lifecycle as a sequence of systems.

How to approach a product initiative as a sequence of systems

Introduction

After catching up with my work and listening this podcast episode, I asked myself the question of, how does a product team approach a brand-new initiative from framing —> shaping —> building —> shipping it to customers.

There are so many angles a team can use to address the following statement from your boss: “hey we need to do [X]”.

Assuming that this is align with company strategy and product strategy, the biggest question we have is, Where do we start from? How are we supposed to do something given the previous statement?

I’m going to tell you how I would do it by introducing the idea of Demand side vs Supply side.

Demand side vs Supply side

I’ve stolen this words from Bob Moesta, when he explains JTBD (Jobs-To-Be-Done) and how to really understand customers struggling moments and helping people to make progress.

Image taken from Business of Software presentation by Bob Moesta - https://www.slideshare.net/marklittlewood/learning-to-build-the-5-skills-of-an-innovator-bob-moesta

In a nutshell Demand-side what struggling moments customers are facing that if solved, would help them to make progress “When our employees are facing risk X, help us by providing Y”. This is the view from the customer standpoint. Supply-side is what your product delivers. Its product and capabilities, such as we can integrate with tool X and it takes just 5 secs to sync the data with X number of fields.

The first thing I would have to ask myself is, do I have a clear view on the demand-side? Is it clear to ourselves what is the progress customers are trying to make? What is the struggling moment they are facing?

Tip 1: before jumping into supply-side, let’s clarify demand-side first. By clarifying the demand-side first, you can establish the flow on why your customer will adopt your product.

From framing into shaping

The progress customers are trying to make, is one the most important inputs to start shaping process of defining the product you will deliver to customers.

The challenge that we normally faces is we toss the team the statement of “hey we need to do [X]” and we expect a team to have something is whatever time-box the agile framework of preference is saying - 2, 3 or 6 weeks.

Here are some of things that are important to consider when shaping:

• What does it mean that PdM, PD, and Eng should work together? We don’t need all the people to participate on every meeting. Be mindful of people’s time and when it makes sense to involve them in the shaping phase.

• When do we come together, When do we do together, and when do we split again ? One of the things I’ve learned over the years is that sometimes, asynchronous time when shaping is more important than sync time. You can discover, get together to discuss, expose your points of view, and deciding how to proceed.

• How do we ensure we’re not over-shaping or under-shaping? Over the years you learn what is the right level of specificity when shaping an initiative. What you want is to give enough leeway to the team to come up with the best implementation by providing the boundaries they can move. I’ve seen that this is a great way when your team is a bit new. Then, they can even break those boundaries.

Deliver a product/project, not tickets

Please keep this statement in mind

Teams should deliver products/projects, not just a bunch of tickets

One of the things I’ve seen over the years in different teams adopting agile frameworks is the idea of obsessing with delivering tickets within a specific time-box instead of looking at the right output and outcome that would help customers make progress.

This idea is tied to understand the entire project / product as a system. The system has inputs that must be model and it must product a specific output that eventually should generate some benefits for the customers and eventually generate revenue for the company:

Image taken from the Business of Software presentation by Bob Moesta - https://www.slideshare.net/marklittlewood/learning-to-build-the-5-skills-of-an-innovator-bob-moesta

If you just think in terms of tickets:

• the team has no idea how they can influence the inputs of the process

• the team has a very narrow idea of what is the output they should produce to address the costumer outcome

• the team cannot understand what are the noise factors that could affect the solution they are building

• the team has no idea what to measure to neither as progress nor as a performance metrics

Conclusion

Each of the phases of product development has inputs, a process, and an output. In the case of “hey we need to do [X]” the only input I have is an idea from someone. Is that enough to frame the problem? Probably not. Then we should start understanding other inputs from other stakeholders to using in the process of framing the problem and come up with potential solutions that could address that problem, to eventually get the most promising solution.

Then we do the same with the shaping phase. We define the inputs in terms of problem to solve, solution, risks or rabbit holes, and constrains. The process of define what we want to implement by also leaving enough latitude to the team to apply their judgement. The output is the high-level document that explains the most important aspects to consider in the development of the solution. This acts as input to the building phase and so on.

Always ask yourself the question of where are you at with the initiative you have at hand and focus relentlessly to define the inputs you are given and which ones are missing. That is the key to build the right process to generate the outputs that are required for the next step.