We have been using the discovery canvas as well as the requirements canvas tool at the very early stage of the company, before doing any sort of product planning at all. This has been really useful as we have seen some patterns and could already identify the main problems we are trying to solve from a customer’s point of view.
There are a couple of things I am still unsure about the requirements canvas process, though.
As we are doing this exercise before any sort of product is built, going through the behavioural driver to the impact and the value is quite straight-forward, however, we tend to struggle more when having to create tangible product requirements. We tend to have requirements that seem too generic and getting those measurable is tricky as we don’t have anything to compare against.
Also, we have created an impact map related to our main short/mid-term goal, which has been really useful and we have also seen some similarities when cross-referencing the impact with the requirements canvas outcomes. I find it a little more challenging to combine the requirements from the canvas, the assumptions and the impact and translate them into actual user stories we can measure. If anyone has some recommendations on how to better combine all these very useful tools into actual stories/tasks the DEV team will use, that would be super helpful.
This is good to hear, a big part of this work is surfacing & testing our assumptions about customer behaviours to make sure we’re actually solving the right problem before we get into the design & build weeds. Once we launch into a design process my experience is that it’s very hard to go back and change the terms of reference of that process.
At this level, the requirements are probably going to be high-level and relate more to customer activity and behaviour. I debated whether to call them requirements, it might be that “constraints” is a better term, what do you think?
The aim is to find a set of constraints that bound solutions we could deliver that will allow us to exchange value with our chosen customers.
Does this perspective help at all?
Again, good to hear.
In my mind, some of the requirements we have generated from customer discovery will become goals that we feed into the impact mapping process since they are going to be about transformations of existing customer behaviour (in service of higher-level goals that might relate to the business itself) and some will be constraints on the impact that might tell us whether one impact or another is likely to achieve a goal.
We could also blend in a tool like RICE scoring into this process to help us with prioritisation.
I’m probably not the best-placed person to talk about how the leaves of the impact map dovetail with an agile process. @paolo, @adrian do you have views on this?
Feel free to post specific examples if that’s helpful, either here or in your own area.