Interesting. But when does the outcomes translated to features?
Let’s say for the basket size increase, there are indeed 4-5 features that could help. In the end, you still need to estimate the effort of each, prioritize among them, and decide which to take and when to move to the next outcome.
I have only experienced ‘feature factory’ roadmaps (which I definitely don’t like), but I find it hard to imagine how the alternative works in practice. In regular roadmaps the features are also connected to some KPI you want to improve.
It seems that the difference is you put the KPI in the roadmap and the team is responsible for deciding which feature to develop in that time. That a good way to make developers involved, but in the end you’ll still have a work plan, no?
Most roadmaps lead to feature factories, which is sad.
The format I used this mean you have to estimate each feature, I would actually encourage to experiment with them as fast as possible to understand what works before making higher investments.
The outcome is the goal, which empowers teams to decide on building or not building features.
Honestly, I’m still not sure how it would look in a practice 😅
Let’s say we tried PoCs in 3 features, and decided to go with one of them, and work on it for a month. We will still communicate that we plan to do feature X, to get some feedback from stakeholders. And than we will commit for a timeframe to release it, no?
Good one !!
Interesting. But when does the outcomes translated to features?
Let’s say for the basket size increase, there are indeed 4-5 features that could help. In the end, you still need to estimate the effort of each, prioritize among them, and decide which to take and when to move to the next outcome.
I have only experienced ‘feature factory’ roadmaps (which I definitely don’t like), but I find it hard to imagine how the alternative works in practice. In regular roadmaps the features are also connected to some KPI you want to improve.
It seems that the difference is you put the KPI in the roadmap and the team is responsible for deciding which feature to develop in that time. That a good way to make developers involved, but in the end you’ll still have a work plan, no?
Most roadmaps lead to feature factories, which is sad.
The format I used this mean you have to estimate each feature, I would actually encourage to experiment with them as fast as possible to understand what works before making higher investments.
The outcome is the goal, which empowers teams to decide on building or not building features.
Honestly, I’m still not sure how it would look in a practice 😅
Let’s say we tried PoCs in 3 features, and decided to go with one of them, and work on it for a month. We will still communicate that we plan to do feature X, to get some feedback from stakeholders. And than we will commit for a timeframe to release it, no?