There’s a new idea in town, and lots of talk about its potential to effect change or bring in revenue. So now the big guns in your organisation have made budget available for you to lead on its delivery. (Lucky you đ±)
The pressureâs on to get to work and go big… but youâre not convinced that this is the best way to get to success.
Meanwhile, youâve heard about agile, Minimal Viable Products (MVPs) and failing fast, but youâre not sure how to sell your organisation on such an approach when the pressureâs on.
Or, perhaps YOU are the team and the money, and this is your vision that youâre bringing to the world. And youâre not convinced that an MVP is worth it when youâre ready to go all in, right now, on developing what seems like a dead cert.
So. Two scenarios but with one shared problem; how to give this idea the best chances of success.
Getting to MVP
We do a lot of workshops that help develop MVPs and define products, but we know the MVP approach is not an easy one to embrace. Launching something sooner, with a much smaller scope, seems counter to big ambitions and targets.
In our work with clients we’ve discovered some common blockers to the MVP approach. So we’d like to raise some of them here and help you overcome them.
Share the solutions with your team, or better still share this blog post đ, and hopefully they’ll help you get to âyes, we need an MVP. We need an agile approach’.
Common MVP blockers:
- “Our idea needs to serve lots of different types of users, and they all need to be on board for it to be a success”
- You’re trying to build an ecosystem, not a product, and that’s getting in the way
- “Are we building an MVP, pilot, proof of concept?” Confusion abounds!
- Creating your MVP is planned to take ages. Is it still an MVP?
- People are wedded to the flashy tech approach
- Your budget is ‘spend it now or lose it next year’. So go big now! (Actually, please don’t.)
1) “Our idea needs to serve lots of different types of users, and they all need to be on board for it to be a success”
The scenario:
The concept depends on a whole bunch of very different user groups embracing it and using it. For example, a new service for charities, businesses, consumers and policy makers.
This is a very risky situation. Everyone needs to get significant value from this concept in order for it to work. And the likelihood that you can deliver the right amount of value to each of these user groups, straight off the bat, is slim.
Moreover, the likelihood that you can do this AND market it to them all equally enough that they all want to sign up, before the other users are shown to be in place, is slimmer too.
Solution:
Focus on one user first. Choose the user with the greatest pain points to find out who will get the most value from your product.
Then refine the concept to focus on them, looking at how you can deliver value without the participation and contribution of the other user groups.
Develop, launch, and when you have built your user base from your first user group, look at how you can then provide value to the next most significant user group. Think about features that solve their problems.
Once you’ve done that you can look at how your product can internally connect these groups together.
If you need help doing this, consider a Design Sprint or a Design Sprint in a Day workshop.
See also…
2) You’re trying to build an ecosystem, not a product, and that’s getting in the way
The scenario:
Thereâs lots of visionary talk about how, when the idea is up and running, services and processes will connect in a successful, codependent harmony.
For example, the Great New Idea sees charities fundamentally changing how they work, and this will be feeding in to new governmental processes and policies. Meanwhile, businesses will be benefiting from these policies, and their end customers will start to undertake new behaviours, and they’ll feeding back to the charities via technical innovations.
Unfortunately, this visionary ecosystem of inter-connectedness is blocking any work from starting. Any proposal to focus work on X results in a chorus âah, but we mustnât forget about Yâ. Worse still, there’s âif we only do that, then Y and Z canât happenâ.
You get the idea. The vision of an ecosystem is getting in the way of starting work on something small.
The solution:
See 1), above.
Also at this stage, you must recognise that there are huge assumptions being made about how these systems work and their points of connection.
In our example, it might be about how charities function, or how policymaking actually happens and the legal steps it must go through, or the types, amount and relevance of data that can be collected, etc.
It is also very likely that you and your team only really understand (at most) one of these systems. If youâre a charity, you know your own sector and processes, and perhaps a bit about policymaking, but its probable that you donât really understand the realities of making a business work, or commercial consumer behaviour.
All the time that it takes to understand an unfamiliar sector is time taken away from developing your concept and getting it to market. Again, thatâs a huge risk of wasted effort should your concept ultimately not be what the market wants.
Again, focus on one user group to begin with. Ideally those with the biggest pain points and hence the most value to be gained from your idea. It might also be wise to focus on the sector that you understand the most.
3) Are we building an MVP, pilot, proof of concept? Confusion abounds!
MVP? Pilot? Whatâs the difference? Do you need both?
In short, an MVP is about focusing on the core of your idea and getting it out the door with the minimum risk, whilst learning from its reception and initial usage as much as possible.
Ideally, if the intention is that this idea generates income, then the very first release should aim to do that too.
A pilot is about rolling out an idea (especially a service) to a large group. The scope for change based on learning is limited – little can be done after the pilot stage except minor tweaks.
I am of the opinion that thinking about pilots now is flawed, as it kicks the hard work of learning from users and making tough choices further down the road.
As such it increases risk for you of getting more wrong and wasting more initial effort.
It also moves you away from the agile approach. About working in risk-reducing, short, regular and repeated phases of learn -> devise solutions -> develop them -> launch -> test -> learn.
If your MVP is a success, you should avoid a âpilotâ phase and instead concentrate on scaling up from there. Successively look at how you might solve more problems for your users.
And if your product has been generating income early, you will get to financial security sooner.
Please note, neither of these are the same as a proof of concept. A proof of concept checks your idea is practically possible. For example, that your product can connect to a certain third-party API, pull some data from it, and do something with it.
4) Creating your MVP is planned to take ages. Is it still an MVP?
It’s going to take, like, 9 months ages.
Thatâs a lot of risk and expense and effort right there. Stop it. Really, just stop it. You can deliver solutions to problems (in some form) in a much shorter amount of time.
That said, the chances are that this is related to…
5) People are wedded to the flashy tech approach
(Also known as âplease donât tell me we can achieve the same results with a blog.â)
The scenario:
This is a really interesting one, and one that I love to discuss.
Here, perhaps youâve already identified your key user and know what their pain points are. You know what value they seek from a successful product.
However, youâre very attracted to using a certain type of technology or approach. There a lot of talk about the tech. People seem wedded to a thing.
At this stage someone might propose (or you might realise) that there may be a simpler way of solving these problems. For example, you can give your users much of what they need via a blog. Or an email newsletter. Or a forum or meetup.
This might especially be true if their problem could be solved with better access to information or through connections with others.
In other words, you could achieve the same results through doing something not particularly ‘innovative’.
However…
Too often innovation is presumed to relate to the technical sense. But real innovation is about getting audiences to do something different in a new way.
People tend to think innovation means using a new framework, rather than the hard work of guiding the audiences through a journey differently.
The solution:
This is a really hard one to accept. I know. So fine, if it makes you/your team excited and happy then aim to build something better than a blog or email list. In fact, I might actively recommend this if the platform itself is meant to deliver desire, because desire and emotional value can be core to a successful user experience.
Being on your sexy platform allows the user to tell a story to themselves and others about their engagement with the product, which reading a blog or chatting on a forum itself wonât provide.
But a blog, for all its lack of sex appeal, is a simple, risk free way to provide the same end goal and value.
Also blogs or info based products are great for another reason. They force you to focus on doing the actual hard work of engaging people directly and saying something.
Youâre not researching tech stacks or planning and building features, but youâre actually putting yourself out there and saying something. Itâs exposing and hard but itâs what youâre ultimately aiming to do – express your opinion and connect with people and create change.
6) Your budget is ‘spend it now or lose it next year’. So go big now!
The scenario:
Your budget is at risk. If you donât spend it all, you might not be given it again.
This leads to big plans, big pressure, a rush to work and too much effort upfront, before youâve tested and learnt from real users.
The solution:
If you really must spend it, commit your bosses to letting you run the project in an agile fashion. Demand that they hold you to spending only a quarter of the budget on an MVP, and insist they make you launch this early. And then youâll divide the rest of the budget on at least three more iterations, post-launch.
If your budget is large, hell, make it 1/6th on the MVP, and then 5-10 more iterations after launch.
Tell your bosses that your MVP product will be a very basic and might even be a dud without much user uptake. But by Sprint 3 it might be showing real traction, and may well have already established itself in the market.
This is a much better place to be in than spending it all up front and launching with fingers crossed that your users will like it.
Also, our experience of working with clients on this sort of project tells us: no matter what your budget, breaking the work into a series of regular ‘sprints’ of activity produces huge efficiencies and better decision making.
This is a much better approach than budgeting for occasional splurges of spend that don’t run consecutively.
In conclusion
Working on your bosses to get to an Minimum Viable Product, seeking to launch and learn from it in the market, is critical. Once it’s launched, scaling it through successive phases of development is vital at cutting risk, reducing wasted effort and increasing the overall chance of success.
If you want to get yourself or your team on board with this approach, consider an Outlandish Design Sprint, which will take your idea through to prototyping stage and will test it with real users.
Or, if you need really to convince sceptical bosses of this approach and you’re working on a tight budget, try getting as many of your team as possible on one of our Design Sprint in a Day workshops. These intense sessions will help you build a unified team vision, define your key users, conceptualise your MVP and create your product roadmap.
