- How Feature Factory Companies Work
- Coordinative Flow: A Logical Way of Working with Unexpected Results
- Nine Out of Ten Ideas Will Fail
- Collaborative Flow: A Simple Way of Working with Outstanding Results
- Key Takeaways
Coordinative Flow: A Logical Way of Working with Unexpected Results
How do you transform an idea into something valuable?
That’s one of the most important questions for companies. A poor answer leads to waste and demotivation.
The beginning of most product development flows is almost always the same. You probably have several ideas and a limited capacity to transform them into reality. The question is, how do you progress?
A coordinative flow aims to carry out ideas from beginning to end, treating each step as a strictly different phase. Figure 1.4 depicts this approach.
![Figure 1.4](/content/images/chap1_9780135335383/elementLinks/01fig04.jpg)
Figure 1.4 How an idea moves from beginning to launch with a coordinative flow
The coordinative flow starts with prioritization, aiming to find the most promising idea. However, that’s easier said than done because several discussion rounds will occur. When you say yes to an idea, you’re saying no to numerous others, and almost no business stakeholder accepts that answer easily.
Prioritization is one of the reasons product managers struggle to sleep. Getting everyone committed to one objective is tough. In a coordinative flow, prioritization will take weeks, if not months.
Design
The design phase starts once you define what the team will work on. The result is often a high-fidelity prototype that business stakeholders approve. This approach is dangerous because software engineers and customers tend to be left out of it. Sadly, the solution becomes the focus, not the outcome.
You may assimilate the design phase as a traditional waterfall process. Yet, having extensive design phases happens with agile methodologies as well. Whether you work with Scrum, Kanban, Scrumban, or something else, it doesn’t matter: The result can be the same. Often, product designers aren’t part of the product team, and teams receive detailed solutions to implement instead of opportunities to explore.
Designing solutions outside the product team is another disturbing bug that requires a hotfix. We will address that later in this book (see Chapter 4).
User Test
After much coordination, business stakeholders finally approve the design, and it’s time to test it with potential customers.
The results are probably compromised because everyone already loves the solution. Sadly, falling prey to confirmation bias isn’t the exception, but rather the typical outcome. Given their passion for the solution, product designers search for positive signs—and unsurprisingly, they find them. They may accept minor solution tweaks, but no solution pivot or drop will happen in this phase.
Develop
After product designers confirm the high-fidelity prototype makes sense to end users, it’s time to develop the solution. Product designers throw the specs over the fence and hope software engineers do the job right. Of course, software engineers aren’t likely to welcome the solution with wide-open arms because they weren’t part of the previous steps. Even so, it becomes their job to transform the high-fidelity prototype into a working solution.
During the development phase, product designers and software engineers often come in conflict. Software engineers challenge the design as they see potential alternatives, and product designers want the implementation to follow the high-fidelity prototype strictly. Together, they find compromises, and none of them are happy about it.
The sad part is the extreme focus on the output. Nobody talks about the customer at this stage. Yet, they keep working on it until the solution is ready for the big moment.
Launch
Given the amount of coordination needed, it takes months to transform an idea into a solution. You shouldn’t be surprised when something takes half a year. Each phase is strictly defined and has many steps to ensure a perfect solution by the end of it. Yet, something unexpected happens when you launch the solution.
Despite all of the internal enthusiasm and love for the newest fancy solution, customers don’t engage with it—and you have no idea why.
You’re sure the design went through rigid feedback loops, the color tonalities are correct, and management approved. The user test took place with at least ten potential customers, and they confirmed they would use the solution because it looked nice to them. Moving from prototype to solution was challenging, but you did it. You’re clueless about what went wrong.
You wanted to celebrate the feature launch. After all, getting to this point required many exhausting discussions and took a toll on your nerves. Inexplicably, you ended with the fanciest piece of crap ever created (Figure 1.5). Sorry about my vocabulary, but recognizing reality requires facing it as harshly as possible.
![Figure 1.5](/content/images/chap1_9780135335383/elementLinks/01fig05.jpg)
Figure 1.5 Launching something and getting disappointed with a coordinative flow
What shocks me isn’t winding up in this tragic situation. I ended there more times than I can count, but I learned my lesson. The question is, what do you do after you face an undesired outcome?
The most common answer makes little sense to me. Go back to prioritization, pick another idea, and do it all over again. When you follow the same approach, chances are high that you will face the same results again.
The coordinative flow forces teams to focus on outputs over outcomes, diminishing them to feature factories.