One year ago, we switched from Scrum to Shape Up. Immediately, we started delivering on time with no delays. We shaped and executed projects with a flexible scope and a fixed deadline, and the product team felt more accomplished because more progress was made and features were pushed to production more quickly, more often, in an incremental way.
Still, the challenge came before shaping and executing. I have seen and read about many teams implementing this methodology; some claim to use an adapted version of Shape Up. I understand why – this method requires a change of mindset, not only for the product teams but also for the stakeholders who contribute or provide input to the projects that will be prioritized next.
At MiSalud, we receive constant feedback from patients through our medical team, from customer support, and from our CEO, who talks to potential buyers all the time. The feedback we receive takes different forms, but the most common one is the form of a feature request.
A feature request is a solution to implement, and even though it is the more natural way of conceiving ideas in this context, it is prescriptive because it prevents product team members from exploring other potentially better solutions. When these feature requests come from stakeholders who are not aware of the constraints and possibilities of the product (which is naturally the case most of the time), they put the team in trouble trying to build a feature that is bigger than necessary in a short period of time, which leads to missed deadlines and unhappy teams, stakeholders, and users.
No backlogs
Shape up is very clear on this: no backlogs. They say: "if it is important, you will remember". I agree. But it is incredibly challenging to get everyone onboard from the get-go. People want to see their ideas on paper.
I worked in consulting for many years, and I understand how these changes, especially these profound changes in the way of working, must be implemented gradually. You need to get your foot in the door, earn the trust through results, and introduce a new change, one at a time. Changes need to be gradual, and often, you need to find middle steps.
Problems over solutions
I looked at our backlog and it was full of solutions that were no longer relevant or were too far ahead in the roadmap. Some of them were added just so someone could see them on paper. Sometimes, during meetings, we would add a feature to the list just so we could move on to the next topic.
The backlog was a big bucket of ideas. Some were grounded on good feedback, metrics, or qualitative research, and some were based on personal preferences and crazy assumptions. Some were based on statistically relevant problems, and some were based on one comment made by one person, not representative of our target market. As one of our primary documents, the backlog was difficult to look at and prioritize.
Then I ran into this article about Lean Roadmapping, and it just made sense to me: every idea comes from a problem to solve, and every new project is an experiment.
I took the backlog and translated every solution into a problem to solve. I discarded the solutions that were not solving any problems, or were irrelevant, or were not solving problems for our target market, and dumped the rest into a kanban board. I called this kanbanthe roadmap, an action that took an enormous burden off my shoulders because of two reasons:
- The roadmap was not a Gantt chart anymore. No more impossible deadlines with features lined up for the next two years. Just a three-column board with the problems to solve now, next, or later.
- There was no backlog. The list of endless features to implement was gone. Yes, now we had endless problems to solve, but it didn't feel the same. A problem opens possibilities instead of adding tasks. A roadmap full of possibilities does not make you feel behind schedule.
The freedom of having problems
When you give a designer or engineer a solution to implement, you tell them what to do. You are practically giving them an order. This not only limits their abilities but also limits the product and the company from pushing better and faster solutions in the market.
Engineers and designers are experts in their field, and, more importantly, they are experts on your product. If you, as a product manager, customer support specialist, or C-level stakeholder, ask these experts to implement a solution that came to your mind, you are not allowing them to design or develop at their level; you are forcing them to do it at yours. Which is not what they were hired for.
Everybody thinks of solutions first. You run into any product that does not behave as you expected and immediately think of a feature they should implement. That's fine. As designers and engineers, we should come to terms with the fact that this is how our minds tend to work. But we should also push ourselves to see behind the feature. We need to think of the problem we want to solve and then give it to our teams so they can devise effective ways to solve it. And if you also give them constraints along with the problem (e.g., we need to deliver something in three weeks), you will get the most creative solutions you have ever seen.
This is what the problem-based roadmap unlocked for our team, but there was still a road to walk together.
Solutions disguised as problems
I presented the roadmap to the stakeholders and used the opportunity of having a "new big project coming up" to run a workshop and ask them to brain dump on problems instead of solutions. I gave them hints and an essential structure for formulating these problems:
(user) struggles with (problem to solve)
After a few minutes, I got good problem statements, such as:
Our patients struggle with joining consultations because they forget how to start the consult from the app
But I also got:
Patients struggle with not having coupons
As you can see, the first is open and descriptive; the second is specific and prescriptive. The second one is not a problem. It is a solution disguised as a problem. The person who created it used the structure I provided but still introduced a solution in the statement. There was no malicious intent behind it, only the old habits that are difficult to change from one day to another. It only took a couple of questions for us to understand the problem behind and frame it correctly.
At this point, I understood it would be my job to curate these problems in the roadmap while people get used to this new way of framing their ideas, and I was okay with it.
Connecting the two processes
From that point, prioritizing was way easier for all of us. Stakeholders didn't ask themselves what should we build next anymore, but rather, what problems are vital to solve now. Surprisingly, we felt more confident about the problems we were prioritizing because they felt real — it is more difficult to come up with imagined problems than imagined solutions.
At the end of each cycle, I would take these problems to the product team, and together, we would ideate and shape feasible and practical solutions to be discussed during the betting table. We didn't just open a space for them to contribute with their ideas but made the act of contributing part of our core process, starting from the top, and they felt more ownership because these solutions came from their minds.
Closing thoughts
Processes are critical. They provide structure and order and increase the quality of our artifacts. But they can also feel restrictive when all the big decisions are made way earlier and team members are put on the merely tactical role of executing somebody else's ideas.
Leaders should decide the "what" and the "when" of the problems to solve (not the solutions to implement). Product team members should be free to define the "how" through the solutions they can only conceive and execute from their expertise and knowledge.