The process of creating and delivering value, or the product pipeline
Hi! My name is Alla, and I’m a product manager for an IT-infrastructure provider. I’m responsible for our “Dedicated Servers” product. It is one of the biggest products in the company, involving almost half of our employees. Recently, we’ve been growing rapidly, and consequently the number of ideas and hypotheses is growing as well. We also have a growing number of customers with different cases and a wide range of feedback.
It is crucial that we stay focused on high-priority tasks, test hypotheses as fast as possible, and spend development resources on valuable features only — and it’s all too easy to drown in the enormous backlog of items. So, to avoid that, we came up with our own version of the process of creating and delivering value, or the product pipeline.
Of course, sometimes there is low-hanging fruit, which we pick, but in general, our hypotheses are large and risky. So we need to take great care with what we are doing and delivering to our customers.
The key point of this article is to have a look at the overall process. I’ll get to the processes of prioritisation, discovery, and delivery in more detail in upcoming articles.
Gathering the information
The process of creating and delivering value starts with gathering information. We research our market of current and potential customers and ask ourselves the following questions: 1) What can we do for our current customers to help them grow, be satisfied with the product, and make them want to bring friends? 2) Who are our potential customers and what value can we add to make them our customers?
We use different methods to get to know the market better and to answer these questions. It can be customer feedback to our support panel, requests from potential customers to pre-sale, hypotheses from product managers, or anything else. All of it goes to the Inbox, or unsorted backlog. The Inbox is not limited in the number of items, but we still need to figure out what to focus on. To narrow the list of items down, we’re going to sort.
Wait, wait! What about competitors? They are part of the market, right? Yes, that’s true. And we’re researching them, but mostly through the prism of potential customers as well as substitutes. So, the full (but still simplified) picture of the market looks like this:
Now let’s get to sorting.
Sorting
The main goal of this step is to decide what to do with each item in the Inbox. There are 3 scenarios:
- Looks promising, but we don’t know if it is really valuable and worth doing → Send to Discovery Backlog
- We know for sure it is valuable and worth doing → Send to Delivery Backlog
- We know it doesn’t matter → Send to Rejected
Of course, there is always a risk of throwing a diamond in the trash. But remember, we have a massive inbox and new items flood in every single day. So, we need something simple to focus on. Also, we can come back to the rejected items at any time — they are not deleted, just hidden.
Who is involved in the sorting?
Product managers and tech leads are involved in the sorting. Why not the whole team? Our team is quite large (20+ people), and it seems counterproductive and expensive to have meetings with so many people, especially when you want to keep it simple.
Okay, we have our discovery and delivery backlogs, but how should we decide what to work with first? Prioritisation is a crucial step, because even if all items looks promising and worth doing, some of them are still more important than others.
Prioritisation
To prioritise discovery and delivery backlogs, we use scoring models. We took RICE and ICE and adapted them.
Hold on — both of them? Yep, both. We spent a certain amount of time figuring out how to invent one model that would work for everything. The main difficulty was that we could not figure out how to compare features for internal users, items that would add value for customers, and UX improvements. And then it hit us! We know to how compare one UX improvement to another, and how to compare one feature for internal users to another. We just needed to compare apples to apples.
We took another look at the items in our backlog and defined several streams of work. Each stream has its own prioritisation model.
The 5 streams we have now:
- Revenue — increases our revenue
- User Experience — improves user experience
- Internal — makes the work of internal users more efficient and enjoyable
- Strategic — explores new customer segments and opportunities for the product
- Platform — reduces technical debt and explores new technologies
You can see the Scheme of Discovery backlog below.
Why platform stream is not there and more about RICE and ICE adaptation for each stream will be in one of the following articles.
I’ll talk more about why the platform stream is not there and more about RICE and ICE adaptation for each stream in an upcoming article.
I want to dwell on the case shown below.
Here we have already assigned priority in the discovery. So, what’s going on with the item on Delivery Backlog prioritisation then? We just re-prioritise it. It makes sense because our confidence has increased, we know more about simplicity/complexity, and we better understand the impact.
Who assigns priority?
The product managers and tech leads assign priority. The whole team is still not involved. The reason is the same as when sorting — it seems counterproductive and expensive to have meetings with 20+ people.
So, we have our backlogs prioritised; now we can move to discovery and delivery.
Discovery
The main goal of discovery is to answer the question “Do we need to do it or not?”. We use all kinds of research, from desk to problem interviews or field research, experiments, and anything else to answer this question.
Discovery work is organised in sprints. Sprint duration is one month, but without fixed start and end dates. Usually we have 20 working days and then we take several days for reflection and the implementation of new tools, techniques, templates, etc. The new sprint starts on the penultimate working day of the month.
The discovery sprint is divided into several stages:
- Discuss (1st day of sprint) — the main purpose is to fully understand the context, discuss the main hypothesis/problem, identify risks, and define research methods.
- Plan (2nd day of sprint) — the main purpose is to identify the list of specific tasks for the sprint. We need to break down everything discussed the day before and evaluate it.
- Do (3rd — 18th day of sprint) — we conduct research and experiments.
- Demo (19th day of sprint) — we demonstrate results and make decisions (Discovery Scoring).
- Retro (20th day of sprint) — feedback loop. We discuss the work process to find ways to improve it.
Who is involved in discovery?
The discovery team consists of the product manager, UX designer, product marketing manager, tech lead, and product analyst.
If we see that it makes sense to invite someone from support, sales, or another department, then we do that. We’ve observed that this is most valuable in the Discuss stage — it helps us dive into the context faster and have less distortion at the beginning.
Of course, discovery is not all we do. All team members are also involved in delivery, but the percent of their involvement differs. For example, a product manager has 70–80% involvement in discovery and only 20–30% in delivery. A UX designer is the opposite.
How do we select items from different streams?
We have several streams (revenue, UX, internal, etc.), and only one discovery team. To keep our work balanced, we define the main stream and stream proportion each sprint. For instance:
- Revenue x 3
- UX x 1
- Internal x 1
- Strategic x 1
So, if we have 6 items, then 3 of them will be from Revenue, 1 from UX, 1 from Internal, and 1 from the Strategic stream. We take items from all streams according to their priority.
Discovery Scoring
Scoring? Again?
We’ve done some research and experiments → increased our confidence and become more certain about its impact and simplicity. It’s time to decide whether we will implement it or not.
There are 3 possible scenarios:
- We’ve confirmed the hypothesis/problem and know for sure it is valuable and worth doing → Send to Delivery Backlog
- We are still not sure and need extra research/experiments to be sure → Send to Discovery Backlog
- We’ve disproved the hypothesis/problem and know for sure it doesn’t matter or will worsen the product (which is much worse) → Send to Rejected
Actually, there is no need to wait for sorting. If, during the sprint, we see that an item doesn’t matter or will worsen the product, we can reject it immediately. It is just a bit easier for us to sort everything in one place to see the full picture.
Let’s take a look at what happens with items when they get into the Delivery Backlog.
Delivery
Finally, we’re moving to delivery. Delivery is all about development and delivering value to the end-users. As you remember, we’re delivering value for both our customers and internal users.
Once an item gets into the Delivery Backlog, it must be prioritised before going to the product development team. I’ve already described the prioritisation process in the section above, using discovery as an example, but it works almost the same for delivery as well.
Once prioritisation is provided, the product managers and tech leads discuss the highest-priority items from each stream and move them to the to-do list for the product development teams.
We have several cross-functional product development teams, and they are free to work using any processes they want. It can be a modification of Scrum, Kanban, or anything else. For example, my team uses a modification of Scrum with a 1-week sprint.
We have common releases for our customer base and internal users, so all the product development teams stay in sync to make it together.
I will take a closer look at delivery in an upcoming article.
Who is involved in the Delivery?
The product development teams; more specifically, the developer, QA, devOps, UX-designer, product manager, and tech lead.
Our process of creating and delivering value or product pipeline is young and we’re just getting started. We’re exploring and experimenting to make this process fit perfectly for us.
Next time, we’ll take a closer look at the processes of prioritisation, discovery, and delivery.
