When talking about product risks, you usually hear the terms value, usability or viability. Companies invest a lot of time in interviews and experiments to find out whether a product is valuable for customers. UX and UI designers optimise the smallest details for a better user experience (usability). Viability, on the other hand, is a well thought-out, strategic decision by the company.
There is literature, dialogue and plenty of experience in the product world for these three product risks. However, Marty Cagan, product thought leader and author, writes in his blog, among other things, about another important type of risk: feasibility risk, i.e. the question of whether a project can be realised in the desired time. The fourth major product risk. This risk is often left to the developers alone. This can lead to implementation problems being recognised too late and even the best UX design not being implemented in time. The project may then fall short of expectations and calculated goals.
What if POs could also gather agile insights here and thus help to reliably achieve milestones? This is exactly what this article is about: we explain our concept of a something like a walking skeleton and how POs can work with the team to address feasibility risks at an early stage.
What is feasibility risk about and why is it important for POs?
Feasibility refers to the implementability of a product: Do those involved have the necessary skills and resources to realise it? This is particularly difficult for POs without a technical background to assess. They have to rely on the team and can perhaps only hope that all competences are covered in order to complete the product on time.
No wonder some POs are tempted to make overly detailed specifications or rely on tight estimates. But risks cannot simply be planned away. Even if the implementation steps seem clear, requirements and conditions can change at any time.
As with other product risks, the same applies here: The earlier assumptions are tested and knowledge gained, the better. Regular reviews can ensure that the product can be realised as planned.
As POs are responsible for entire products, feasibility should be just as high a priority as value, usability and viability - even before the implementation phase.
How can POs assess feasibility at an early stage?
In an agile context, POs are responsible for backlog management and maximising product value (see e.g. Scrum Guide). But how do you deal with technical risk, especially in early development phases?
This is where close collaboration with the development team helps. POs should not only prioritise the backlog, but also work with the team to identify which technical risks need to be addressed early on.
POs can enter into the discussion on the feasibility risk with the team by asking specific questions:
- How does the product fit into the corporate strategy? What are its overarching objectives?
- How does the product fit into the existing system landscape? Which interfaces are relevant?
- Where are the greatest uncertainties in the technical implementation?
Dependence on other systems often hide unexpected risks. If a product is technically perfect, but critical data is missing or cannot be consumed as expected, delays occur.
Why these questions?
1. How does the product fit into the corporate strategy?
Before POs deal with feasibility, it should be clarified with the team why the product is strategically important for the company. Is it about reducing costs, increasing efficiency or market growth? This clarity helps the team to make decisions based on the company's objectives. After all, there is often not just one technically correct solution, but different paths with varying costs and efforts. POs should challenge the development team to take responsibility by making technical decisions based on business strategy and goals (see our blog on The role of software developers: from technicians to product developers).
2. How does the product fit into the existing system landscape?
As a PO, you are used to looking at the product and rarely at other systems that affect you. However, this is often where the greatest feasibility risk lies. A product can be perfectly designed, but if data is not available as expected or interfaces work unreliably, this can lead to delays or even failure.
POs should therefore work with the team to clarify how the product fits into the existing system landscape:
- Which systems does it need to be connected to?
- What data is required, where does it come from and how is it processed?
A dependency diagram that shows the relevant systems and interfaces helps enormously here.
3. Where are the greatest uncertainties in the technical implementation?
Once the business objectives and system landscape have been clarified, the next step is to identify the greatest uncertainties. Which dependencies are critical to success? Where are the interfaces still the least clear? This is where an iterative approach helps to test the key technical challenges as early as possible.
With clear goals, a good understanding of what the product depends on and an assessment of the implementation risk, the backlog can be prioritised, especially in the early phases of the product, so that feasibility becomes more secure step by step alongside value, usability and viability.
Why MVPs, milestones and estimates are not enough
Many POs rely on MVPs, milestones and estimates to structure implementation. These approaches all have their purpose, but when it comes to feasibility, these methods often fall short:
- MVP: Defines the minimum functional scope, which can take months to implement.
- Milestones: Are intended to make progress visible, but can still be too large and inflexible when it comes to minimising risk.
- Estimates: Convey predictability, but are based on assumptions and contain uncertainties.
- Proof of Concept (PoC): Technical feasibility studies are helpful, but are usually not designed for productive software.
After POs have done this important MVP and milestone planning and carried out estimates with the team, all that really remains is to watch from the side and regularly ask whether everything is still going according to plan.
This is why a complementary approach is needed to continuously check feasibility.
The solution: A type of walking skeleton
A walking skeleton, as we use it, is the simplest functional connection of all critical system components. It tests the real challenges at an early stage and helps to quickly eliminate uncertainties.
Examples:
- An analysis tool is useless if it does not receive valid data.
- Data preparation software without stable output does not provide any added value.
- An online shop without real-time product data cannot fulfil user expectations.
POs can do very valuable work here by planning and executing the following steps with the team to achieve a functioning walking skeleton:
Step 1. identify core functions on which the product depends
Step 2. prioritise the riskiest components and interfaces in the backlog
Step 3. set a functioning technical MVP as the first milestone - preferably after three months at the latest
Step 4. expand the product step by step based on the knowledge gained
Our kind of walking skeleton consists of working software that addresses the most critical feasibility risks. Unlike a PoC, it is not just a test, but already a real building block of the future product.
All advantages at a glance: Why a walking skeleton is important
Many development projects fail not because of a lack of value or poor usability, but because of unexpected technical hurdles. Our type of walking skeleton ensures that these become visible at an early stage.
Advantages:
- Early clarification of dependencies and technical challenges.
- Reduction of uncertainties through functioning software.
- Faster learning curve for the team, as assumptions are checked directly.
- Flexibility in further development, as the technical MVP can be expanded step by step.
- Increased understanding of the product and sense of responsibility in the team to assess and minimise risks through the strong involvement of the development team.
Conclusion: POs should actively manage feasibility
As a PO, you take responsibility for value, usability and viability - but also for feasibility. POs should not passively wait for developers to work through all the tickets only to realise at the end that everything is delayed.
Instead, POs can actively work with the team on an implementation plan that identifies technical risks early on. This type of walking skeleton delivers working software early on, clarifying the biggest feasibility issues and helping to ensure that the product is implemented successfully and on time.