At a first glance, getting from product initiative to product release may look complicated. I often asked myself “When is the right time to involve the development team?” or “When should I write user stories?”. And sometimes I didn’t know if I communicate enough with the stakeholders.
I understood at one point I was overthinking the flow, trying to find the fastest route to start implementation. But skipping steps is not recommended because it leads to ambiguity, which can delay the result.
After several attempts, I’ve found what best worked for my team and me. So I’ll provide in the steps below details on how I approach new initiatives. If you are interested in finding out more, read below how as a product owner, I manage this entire process successfully.
Step #1: Understand customers’ needs
This is the beginning step that will lay the foundation for what you’ll build. A good understanding of what customers need will lead you to deliver a product that will simplify aspects of their activity.
A poor understanding of what users need will lead to a product that no one will use. How can you make sure you understand all the important details?
- Discovery sessions
From my experience, there can be two main situations you can find yourself in. You either need to change something in the existing product or you want to introduce new functionality.
It’s important to assess which one of these situations applies. You may need to consider some existing systems that have to integrate with the new initiative. Or it may be something you have the possibility to envision from scratch.
Find out the key requirements that will give them the value they are searching for. And don’t forget to take notes of every aspect, even if it doesn’t seem important at that moment.
- Analyze the requirements
After the discovery session, you should have enough material to analyze. But you don’t have to do it by yourself.
You can meet with your UX team and other product owners within your organization and brainstorm questions and solutions. These are questions you will have to go back to the customer with.
Many questions arise when you take the time to analyze everything you discussed in your discovery session. We can identify many scenarios we didn’t even think about.
However, the discovery phase doesn’t stop here. It’s good practice to go through these steps a couple of times. This is to confirm the customer’s requirements are well understood and prioritized. But also this way you’ll know how to measure the success of this initiative.
Step #2: Add all the information you gathered on a visual board
The development team plays an important role right from the beginning. Before documenting all the requirements, I have a high-level discussion with the developers. They can offer many details, even if they are technical, that may change the way I think about creating user stories.
- Have a user story-mapping session
User story mapping is a great technique to identify the flow users will go through using the product. Depending on what we have to build, I have two approaches:
- If what we are trying to build involves frontend work for users to interact with the product, I begin the story map together with UX. With the customer’s requirements in mind, we set up the steps users must follow within the product. It’s also time to identify some initial release goals and what the MVP comprises.
However, it’s important to remember that the initial release goals cannot be too precise in Scrum. Things may change when we get the estimates from the development team and as the work continues sprint by sprint.
Once we have identified the key steps and activities with the development team, we can start the story-mapping workshop. Here, we brainstorm extra activities and steps that might be missing. - We sometimes have to work on functionality in the backend without affecting what users see. For example, we can think of database improvements, implementing levels of security, or improving the performance of our product.
A user story mapping session is not useful anymore in this case. Here, we have sessions where we talk about how can we structure the work, estimate it and add it to the backlog.
2. Aim for a high-level estimation
Now that everyone has the same understanding of what is being built, the development team should now have the possibility to come up with a high-level estimate.
We aim to identify if the entire product development would take between 3-6 months or more than that. We are not looking to estimate on a user story level at this point.
3. Revisit the initial release goals
Some changes can appear in the way you prioritized the MVP, once the team has given the high-level estimation. You may have to de-prioritize some of the work items.
And this is something that’s expected to happen at this point. The purpose is to identify potential risks, dependencies, and unknowns that can interfere with your release goals.
Also, you may identify risks that lead you to think over the release goals or question the placement of the current initiative on the roadmap. Maybe it’s not yet the time to dive into it. Now is the right time to stop the process and re-assess the priorities.
Step #3: Build the product backlog
You have all the information you need to create user stories: customer requirements are well-defined and understood, dependencies, other scenarios, and high-level estimations were determined in your last workshop.
Begin documenting the user stories and bring them to the refinement session. The team will estimate each story individually and can start the work in the next sprint. And don’t forget you need the UX team to help you out here.
The aim is to start the work and gradually fill out the description for each story. It’s not recommended to invest a large amount of time in defining all stories at once, because during development, some changes may be needed.
Once you have them all added to the backlog, the ones at the top should contain the most details and the ones at the end, less.
You can read more about how to build, order, and maintain the product backlog in this post.
Step #4: Plan the release activities
Not every sprint result has to be released to production. Sometimes it is possible to release items to production each sprint, but other times we don’t have a releasable piece of software. And this is most often seen when we are working on new initiatives.
Release activities often include collaboration with the marketing department within the organization. When we launch a new product, we want to make sure our customers and potential clients learn about it. Landing pages and newsletters advertise what outstanding features or products we are about to release.
This requires good synchronization between the Product Owner and the marketing department. Especially if major changes will be included once the result will reach production. You will want to inform the customers about any changes that will interfere with their usual interaction with the product.
Step #5: Measure the initiative’s success
Work is not done when the last user story reaches production. Setting up success metrics is an important step, it’s a way of tracking achievement.
This will allow you to observe how users are interacting with the product. It can show if the engagement drops or increases. With all these details, you can make an informed decision regarding future steps.
Following production, we have to pay attention to customer feedback as well. Customers are the ones who we are building products for so, what we create has to be something they need. If it’s not, there will be no interest in our products.
Conclusions
The way we manage the steps between the moment a new initiative comes up and the time we release the work to production may differ from team to team, or from one organization to another.
However, these steps can be applied in most cases.
The flow I have described above works very well when stakeholders are direct customers. But also when stakeholders are colleagues from other departments within your company. This approach works whether you are adding a new initiative to the product, or creating a new product from scratch.