If you want to switch from waterfall and are new to agile there are many resources and blueprints available to get started and to tell you what to do next. There are courses to take and books to read and experienced people to learn from on how to build, test and ship software in iterative and continuous way.
But what about all the activities that we do to decide what to build? Is there a blueprint we can follow on what to do next so we can make informed decisions on what to build? If you are like me, you have come across all different methodologies like Design Sprint, Jobs To Be Done, Lean Startup, Customer Development and Design Thinking over time and the question is, how do we know if these tools are helping us, and how do we know what to use when? How do I decide which ones are right for my team?
I came across a (long) blog post followed by a video of Teresa Torres that answered all the above questions. Take a look at the video:
In Summary, her idea is to build a decision tree (she calls it Opportunity Solution Tree) to make sure that we have thought about different aspect of what to build. The root starts with finding what the clear desired outcome is. We need to define a qualitative objective, combined with quantitative key results, so that we can measure if we are getting closer to our desired outcome. Next comes as identifying opportunities (which is the fancier word for problems and pain points you want to build solution for) and only after these two levels are clearly defined you can compare and categorize solutions and ideas to see if they tie back to the making better outcome.
The great thing about Opportunity Solution Tree is that it gives you the blueprint I was craving earlier. This means there is a systematic way to use different methodologies at each levels to identify the problems/opportunities, solutions and validate if the proposed solutions will work. This is helpful to me because it it helps me to identify which method to pick. Take a look at this diagram here. In a glance I can now see Jobs-To-Be-Done more focuses at defining the problem but tools like design sprint talks more how to build the solution.
One final note is like Agile concepts, I think this mapping concept is easy to understand but hard to implement. I am trying this at work right now I will let you know how things go!