Building new products or developing existing ones is a complex challenge. There are many ideas, and resources are always limited (even if only human). It is impossible to do everything at once. What is more, it would be a mistake to implement every idea that comes to mind. How to decide and what to tackle first? How to assess whether a given idea is good? Is it worth implementing?
The answers to the above questions usually stem directly from the company's product culture and the decisions made are in line with the accepted values. It also happens that Product Managers are left with full freedom when it comes to determining the flow of current work - in this case it is often just to deliver the result. Regardless of whether the approach is a result of organizational culture or remains in the PM's scope, in order to achieve good results it is worth building a process. A process that will enable continuous and repeatable product development and growth.
Experiment continuously
To increase the chances of success of your product (or individual functionalities), you should look at building a product as a process, an arrangement of consecutive stages that consists of specific elements.
In this article I will present a framework based on Hypothesis Driven Development with ready-made templates that help you focus on what is important. This approach allows you to think of the development of new ideas, products, and functionalities - as a series of experiments to determine if the desired result (outcome) will be achieved. The process is repeated until the desired outcome is achieved or the idea is determined not to be "viable."
This approach uses a Kanban board to facilitate agile product management, and when combined with additional materials, supports idea development with a focus on outcome design. It is ideally suited as a tool for the Product Owner whose goal is to get as much value from the product as possible. It assumes a phased approach consisting of several steps – from the idea, through implementation to deciding what to do next. In the next part of the article you will learn the details of each of the stages, which are:
- Idea Box
- Discovery phase
- Product Backlog Management & Development
- Most importantly, what's next?
Kanban template - https://miro.com/app/board/o9J_lciytlk=/
Stick to the rules
A vision, a strategy, or a roadmap are undoubtedly essential elements for a successful product. You should be focused both on the coming weeks (in scrum, for example, on the next sprint) and instilling a visionary approach. If you care about product growth, you need to find the right balance between "small" and "big picture". The following three principles will help with that:
1. Implement the strategy
The majority of tasks undertaken as part of the teams' work should result directly or indirectly from the company's strategy. A proven method for its implementation is the use of OKRs (Objectives Key Results) or OITs (Objectives, Indicators & Tasks – a derivative of OKRs used e.g. in ZnanyLekarz and Tidio, proposed by Lucjan Samulowski). A good practice is to determine in advance how much time you will spend on strategic tasks (e.g. 70%), and how much space you will leave for more ad hoc ideas, refactoring, or fixing current errors (e.g. 30%).
2. The long run is unhealthy
It is worth remembering that in a dynamic environment and under conditions of uncertainty (welcome to the startup world!) it is very easy for priorities to become outdated. What is important today may no longer be relevant two months from now. Every idea should have a defined time, after which it will no longer be considered. If something sits in the backlog for a long time or has not been well thought out, it means that it is not important. Don't be afraid to put aside even those perfectly developed ideas. You can always come back to them, if necessary. Now focus on what's important.
3. Sometimes less equals more
More and more often I come across the idea that multitasking doesn't work. Apparently, the more tasks we have, the more time we spend switching contexts rather than doing them effectively. Unless the activity is mechanical, we are generally only able to focus on one challenge. Especially if it is an intellectual challenge. And after all, that's all we have to deal with when building products online. That's why it's worth imposing a limit on the number of tasks in progress (limit WIP), recognizing the laws of nature, which effectively make it clear that you can't split in halves, and the ability of bilocation appears only in fairy tales.
Define problems (Idea Box)
First, you need to have a good understanding of your users and their real-world problems. This is important because only their point of view is suitable to be juxtaposed with your business goals and strategy. This will allow you to verify their satisfaction, detect and fix bugs, develop specific functionalities, work on retention, and most importantly - make better product and business decisions. There are many ways to power Idea Box on a continuous basis.
It's definitely worth designing a process for receiving feedback from customers. It's worth focusing on automation, e.g. by asking questions while measuring CES (Customer Effort Score) or NPS (Net Promoter Score). You cannot also do without more qualitative research, which allows you to get to know your users better and understand how your product helps them in their business or what problems they have.
So how do you define the problem accurately and decide if it is worth addressing? There are many approaches available. My favorite is to approach each issue by dissecting it:
- Problem - naming things by their proper name, i.e. presenting a factual situation
- Reach - to determine which population is affected
- Customer Impact - how solving a problem will translate into customers
- Business Impact - will it improve business metrics
- Evidence - detailed data about the problem
Sometimes it is also worth considering the Cost of Inaction, i.e. what will happen if we do not solve a given problem. It may turn out that something is desirable, but it is not necessary.
Analyze ideas (Discovery phase)
Before you decide whether it's worth building a given product or implementing a given functionality, it's worth looking at the issue from a broader perspective. This is important not only for the Product Manager, but above all it helps the development team to better understand the topic. After all, the team will be responsible for the implementation and further development of the product. A great tool here is the Lean UX Canvas, or the Validation Field proposed by Tim Herbig.
It allows you to structure the idea validation process by defining success metrics and, at this stage, deciding on the next steps. It is also worth considering three scenarios - positive, neutral and negative. That is, what will indicate that the experiment ended this way and not the other, and what you will do about it next.
Validation Field template - https://miro.com/app/board/o9J_lcihlNg=/
Show it to the world! (Product Backlog, Development)
In fact, everything we do when building or developing a product is experimentation. Proof of Concept, MVP, version one, version two - you name it. Regardless of the terminology, what you're doing can produce the result as intended, or the opposite. However, any result will be good as long as you can learn something from it. To learn, you need to instill in yourself an experimental approach, and when designing new products or functionalities, know what you want to achieve. It's very easy to translate previously developed issues into an experiment ready to be implemented. You already know what you want to achieve, how to do it and what the proof of your success will be. So it's time to move to action.
However, you can't do anything alone. It's worth involving the team in every stage of the process - two (or more) heads are better than one! Use scrum Refinement to detail the tasks to be done (here are some hints from Piotr Górajek on why it's worth breaking a sweat in training to save blood in the sprint ring). The form is up to you. You can use the most popular ones, like User Stories or Jobs To Be Done supported by detailed acceptance criteria, as well as those less known, like the technical-poetic language Gherkin used to create test cases, which originates from the BDD (Behaviour Driven Development) approach.
Practice shows that combined forms work best. Don't limit yourself to one approach. Mix forms and find the one that works best for you. Below is an example of one of the functionalities recently implemented in Tidio as an experiment aimed at increasing chatbot adoption (a combination of User Stories and Gherkin/BDD):
Always try to keep a well-developed top of the backlog. If the backlog itself is not clear enough for you, don't be afraid to create something like a draft of the next sprint (e.g. Draft Sprint) and make sure it doesn't leave too many questions open. At this stage, all tasks to be performed should be clear and legible, and the expected results should be known. This approach also helps to maintain transparency of what will be created in the near future. So what to tackle first? What is most important?
As it happens in IT - it depends. There are at least a few approaches you can use to set priorities, such as the MoSCoW analysis or the Kano Model. Check which one works best in your case and use it to decide what to do next. Below is an example of MoSCoW analysis proposed by my colleague Piotr, taking into account the mapped competition, team feedback and user requests:
MoSCoW analysis template (competitors, team & users) - https://miro.com/app/board/o9J_lcihlKw=/
Then it's strictly a scrum process. What you should pay attention to are the sprint goals that contribute directly to the strategy. The increment should reflect the tasks planned in OKRs/OITs. After all, without strategy there are no results, right?
Measure and learn (Done - what next?)
"Work is never done." This is especially reflected in the context of product development. As long as we see growth, we will most likely have something to do (assuming business goals are met). The iterative approach doesn't end with the release of a given feature or after a given experiment. It's just the beginning.
What’s most important is whether you've learned something because of it. Will you be able to use the new information to your advantage? Will your decisions be based not only on intuition, but also on data? This is where we come full circle when it comes to our feedback loop (build - measure - learn). If the completed experiment has a positive result, you can iterate further. Don't rest on your laurels. Optimize. In this case, it's worth drawing conclusions, discussing the topic with your team and trying to squeeze even more out of it.
But what if the result is negative? Go back to basics. Ask yourself if you have addressed the problem well. Did you make the right hypotheses. Whether you were able to collect useful quantitative and qualitative data. Go back to the Idea Box. Maybe the problem can be solved in a different way? Or maybe it’s just enough to apply a few cosmetic changes and the results will be completely different? If you still haven't managed to collect any concrete, real data that will help improve the product - change your approach. You can't do the same thing over and over and expect different results. Experiment with other approaches. Ask for help. Two heads are better than one.
Focus on what's important
A well implemented process should support the discovery of how to deliver value to users in such a way that we can meet our business goals. And how to do it in a continuous manner.
Hopefully, at least some of the tips mentioned in this article will help you better generate product development ideas and be a support in gaining insights that will allow you to grow. However, don't try to do everything at once. Implementing processes also requires an iterative approach. Pick one thing and test it. The proposed framework works best for big challenges that require a holistic approach.
