Product owner, work on your strategic helicopter view
Agile being is essential for dealing with the dynamics of a tech project, using your budget effectively and embracing change, even if it happens halfway through your project.
But the idea that rapidly rolling out features is the best way to learn what the market wants is almost always a pipe dream. Yes, in theory, you can release a new version every 2 weeks, collect usage data and adjust your backlog or possibly make a pivot based on that. In practice, this almost never works. By the way, even if this works, there are better ways to learn. After all, building and then deleting features is much more expensive than pre-validating them.
How 'done' is' done '?
Legislation, infrastructure, procedures and cold feet usually mean that the result of a sprint doesn't even reach the market at all — or only much later. Under the pressure of the circumstances, the definition of done quickly down to something like “delivered to Acceptance”. Meanwhile, due to various internal factors, the MVP is getting bigger and the launch is postponed.
And without releases, no usage data. So if you rely on your release speed for your market knowledge, you are taking a big risk. Agile So working only works in combination with 'top-down', strategic thinking. Because where hard data is missing, an agile development process also needs vision, strategy and frameworks.
The 4 most important risks
Developing a digital product starts when an idea, often in the head of a CEO, founder or business manager, a business case and sufficient investment money come together. But an idea and a business case are always theory.
It is the task of the product owner to use the investment budget as efficiently as possible to convert the idea into concrete market value and thus make the business case a reality. If that sounds like a huge challenge, it's because it's also a huge challenge is.
The risks a company faces when matching an innovation to the market are serious and can be divided into 4 categories:
- The product works, but customers don't buy/use it (the “value risk”). You won't be the first to build a beautiful solution to a non-existent problem...
- The product meets a need, but users don't find or understand it (the “usability risk”)
- The idea is good, but you can't get it done technically (“Feasibility Risk” and “Scalability Risk”)
- The solution works, customers use it, but your organization cannot support it in terms of sales, marketing, service or legal, or the business model as a whole does not work (this is the “viability risk”)
The question that everyone always asks you as a product owner is: “What should we build now?”
In finding a good answer every time, tackling these risks smartly is crucial.
One small problem...
There is one small problem: you have no idea. You won't know if a feature is successful until you roll it out and get access to usage data. So that's easier said than done. At the start of the project, you still have no data anyway, so the decision comes down to your strategic vision of the customer, market and product.
You should not only develop that vision, but also substantiate it with arguments. First, you have to convince your client or CEO, who also has a vision of where to go. Most often, these are people with a strong personality, who are not afraid to be firm about what they want and what they don't want. Has the CEO decided that a certain feature is the absolute moneymaker is going to be, but do you still want to let the team build other things first? Then you have a tough discussion ahead of you where you need to come up with objective and solid evidence.
On the other hand, your development team wants to work. Gifted, driven professionals who want to do meaningful, challenging work. And who become restless after just half a day without such a challenge. They also have an opinion about everything and therefore want to hear a substantiated story about why you (not) make certain choices.
Everything is an assumption
You get the basis of your vision from a broad, strategic view of risks, because at the beginning of the project, everything may be an assumption, but not every assumption has the same amount of risk. So invest some time in identifying your most important assumptions and the associated risk.
For each part of the business case, ask the questions:
- Which assumption lies below?
- What is the impact on the project if this assumption turns out to be wrong?
- How can I test this assumption as cheaply as possible (spoiler: you can test many of the assumptions without building anything)
This way, you can find out where the biggest risks lie. And which assumptions you should test first. Each assumption has its own most effective method of testing, but whether you're doing desk research, interviews, data analysis, or UX workshops, they all take time. Plan that time in your roadmap.
Launch it earlier than you feel comfortable
And, speaking of roadmap and runway: no matter how short your runway is, it's smart not to use it entirely to build an MVP. Because putting an app live is great, but in fact, it's only then that the work starts. Now that your customers are really starting to use your software, you're finally getting your usage data, so you can finally learn from real users. It would be a shame if that's exactly the time that your development budget also ran out. So always set goals beyond the MVP and prefer to launch your MVP before you feel comfortable. For example, bringing in the first 10 paying customers. Or tapping into a new niche market. Communicate these goals clearly with your stakeholders and reserve a budget for them.
Working together on the strategic helicopter view
All of this means that you need to occasionally adjust your tech team and ask your CEO to spend some budget on market and customer research. That seems inefficient, but by gathering knowledge now and thinking smartly, strategically, you will save a lot of budget later in the process.
To get your CEO and investors on board with this approach, dare to also uncover assumptions in their vision and include them in your validation plan. This is how you develop a “strategic helicopter view” of your product together, monitoring throughout the project how the product fits the business strategy, how the investment will best pay off and how the product will ultimately generate money.
Want to read more about our vision of the role of the PO? And do you want our 4 golden tips for delivering successful projects as a product owner and working on your own status in the organization? Then take a look at our white paper Why you don't want to become a product owner (and 4 things to do if you're already a PO and want to deliver successful innovations)
.jpg)
