(Using David Bland's Guidance on assumption mapping, the goal is to identify the "leap of faith" assumptions we are making behind this idea)
Desirability:
[x] We believe that the target customer for our solution is: CTOs of startups or tech leads of Service provider businesses.
[x] We believe that our value proposition to our customers is: Saving time and money getting up and running right immediately, with a known starting point (template) and known way forward from there.
[x] We believe that customers can or cannot solve this problem by: can start from scratch and will spend time and money getting to the same place with varying degrees of support for continuing forward.
[x] We believe that we can reach our customers through: key developer influencers, and industry publications, to employees, to startups.
[x] We believe that we can keep our customers by: producing an outstanding outcome for them, using already known ingredients
Feasibility:
[x] We believe that we can address legal and regulatory risks by: open source and issuing restricted licenses
[x] We believe that we can solve for the technology challenges by: already having that knowledge in-house, with future research to keep up with change.
[x] We believe that we can hire and keep the right team because: we are experienced at doing that already, and this problem is desirable to solve for a whole class of competent software engineers looking to flex their skills.
[ ] We believe that we can sign key partners by: <unknown>
[x] We believe that we are uniquely positioned to win because: we have the experience of doing this for small service providers.
Viability:
[x] We believe that we can generate revenue by: selling and restricting a license of the software.
[x] We believe that we can keep our costs low by: keeping the team small.
[x] We believe that customers will pay a high enough price because: only if the value proposition is easily understood and obvious to them, whereas the alternative is far harder to predict.
[x] We believe that we can make a profit because: there are enough service providers out there looking for a common stack to get started on, but only if we can reach them.
[ ] We believe that this aligns with our vision because: <unknown>
Next, map out the assumptions you’ve written down together as a team.
The shared understanding generated by the mapping conversation is much more valuable than the
map itself.
Draw the X axis first and map ‘have evidence’ vs 'no evidence’. Then draw the Y axis and map ‘important’ vs ‘unimportant'.
Experiment on the top right quadrant to generate evidence for these important and unproven assumptions. Remember to run experiments that match the desirable, viable and feasible assumptions, otherwise you won’t generate valid evidence.
Share the top left quadrant with your team. Are these important assumptions supported by evidence and already accounted for in your plan?
Defer commitment on everything below the X axis for now.
This map is a living document and is an iterative process. Take snapshots of it to document how things have changed and what you’ve learned over time.
(Using David Bland's Guidance on assumption mapping, the goal is to identify the "leap of faith" assumptions we are making behind this idea)
Desirability:
CTOs of startups or tech leads of Service provider businesses.
Saving time and money getting up and running right immediately, with a known starting point (template) and known way forward from there.
can start from scratch and will spend time and money getting to the same place with varying degrees of support for continuing forward.
key developer influencers, and industry publications, to employees, to startups.
producing an outstanding outcome for them, using already known ingredients
Feasibility:
open source and issuing restricted licenses
already having that knowledge in-house, with future research to keep up with change.
we are experienced at doing that already, and this problem is desirable to solve for a whole class of competent software engineers looking to flex their skills.
<unknown>
we have the experience of doing this for small service providers.
Viability:
selling and restricting a license of the software.
keeping the team small.
only if the value proposition is easily understood and obvious to them, whereas the alternative is far harder to predict.
there are enough service providers out there looking for a common stack to get started on, but only if we can reach them.
<unknown>