tl;dr — MVP on acid; build a sentence, not a list of features. Validate very early, fail faster and let the roadmap be driven by real use. Build things as quickly as possible, initially doing things manually where you can to form a real connection with your users.
Most products and start-ups fail because people spend lots of time and money building cool, gorgeous, awesome, totally useless things (according to CGInsights, ForEntrepreneurs and Fortune.) Ideas are easy, execution is tough, but selling a product that nobody wants is almost impossible, and the latter is a deal-breaker anyway; so let’s start there.
The first thing we should do is validate our assumptions about what users want before committing to build it. Talking to users and taking the time to understand the problems they face is vital, but it can be tough when you are discussing abstract or conceptual ideas. So building something for them to play with, to touch, to feel, to live with, to break, makes all the difference and moves the conversations away from the meta.
Doing one thing
Lots of people already know this, and nowadays it’s pretty trendy to assert that your exciting new product should,
“do one thing, and do it well.”
Others struggle with this idea because the websites and apps they use every day do lots of things, not just one. But it’s important to remember that they didn’t start that way.
Remember the first iPhone? You couldn’t install apps on it. What? Useless right? Not according to the people who bought 6.1 million of them in the first five quarters, of which the author (me) was one. Looking back from the current product position of the iPhone, the first generation edition has a small fuzzy screen and is slow and clunky, heavy and limited. It’s not fit for purpose from our perspective; it’s a halfthing.
The trouble is, our imaginations can take us far into the future at the speed of light, bypassing lots of pretty important steps that would need to occur in the lifecycle of a project on the long road to success. We know too much. And the more we think about it, the more we design it, the more we fall in love with what it will one day become; the more useless and pathetic the early version seems. This artificial engorgement occurs whenever we have conversations with other people, be it our friends, colleagues, stakeholders, investors, potential customers etc. as more and more ideas are thrown into the pot.
So the ‘one thing’ grows and becomes a pretty big thing, and now it needs to do A, B, and C in order for that ‘one thing’ to be useful at all. And we have to wait until the ‘one thing’ is complete before showing somebody else otherwise they’ll steal the idea and do it better. And anyway, the ‘one thing’ isn’t enough to have the impact we know our app will have, so maybe we should actually be doing two or three things?
This is akin to focussing on what your new baby will be like when she has grown up and sitting impatiently by her cot checking your (limited first generation Apple) watch, waiting for her to speak or walk or get a job or something. Well stop it. She’s just a little halfthing, and that’s OK.
Minimum viable product
A minimum viable product has just those core features that allow the product to be deployed, and no more. The product is typically deployed to a subset of possible customers, such as early adopters that are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information. It is a strategy targeted at avoiding building products that customers do not want, that seeks to maximize the information learned about the customer per dollar spent. — Wikipedia
Even if you’re pretty comfortable with the theory of MVP it’s easy to get pulled onto the dark side by your excitement, fears, naiveté, or those of the people you are working with. After all, who decides what the minimally viable product is? And how do you know you’ve got it right? The secret is, you don’t know. Nobody does. Let’s just admit that, and get past it.
Real example
Let’s pretend that we are going to build an app together, and explore what a version one would look like; and you’ll see why it’s useful to think about halfthings instead.
We’re going to build an app that lets a group of friends share their locations on their phones so they can easily meet-up. It will be called TinyPins (people will be represented by tiny pins on a map.) Let’s think about what kinds of features this sort of app will have:
- Sign in using Facebook, Twitter, Google, or LinkedIn (ohh suddenly it’s good for business too — maybe we’ll go and pitch it to some businesses)
- Build a network by inviting people to connect with me, and grouping them so I can deal with people differently
- Indicate how long you want to share your location for — maybe per group
- See the pins of my friends on my phone live
- Take payments for pro use
- Chat with my group to make decisions while we’re waiting to meet up
- Search for equidistant cafes, bars or restaurants that we can meet up at
We haven’t gone mad with ideas here — the list represents a pretty standard featureset for this kind of app. Most people would say that these features represent a good version one of TinyPins. After all, they can probably think of all kinds of features that aren’t included (vouchers, estimated time of arrivals, directions, etc.)
That would be putting the cart before the horse because we have no idea if people even need this kind of app or not. Sure it seems like a great idea, and a fun one but will people use it?
Which features from the list above would you choose for the first version? A typical planning session might go like this:
“Well the app would be pretty useless if you couldn’t sign in, right? So that’s definitely in. Maybe we just pick one authentication provider since we’re being all cool and agile and MVP about it. Then we need to share our location obviously, and control how long for because people care about privacy, but maybe we’ll just offer three options; always, for today and for the next hour. And we’ll definitely need to add people to the network, otherwise how will it know who to share my location with? And if nobody can see the pins, then the app is pointless so we’ll need that too without question. And our investors have made it clear that we need to make money, so we’ll need to be able to take payments, we can just use the Stripe API so that’s easy. And how cool is that last idea about finding places to meet that are walkable for everybody; when we tell people about that they get really excited, which makes our pins on a map thing look a bit limited. And Jonny had an idea last night about adding a voting capability to decide which place to meet at — which is awesome and fun and we could even shake the app to have it select randomly. We can’t release without that killer feature!”
Oh dear.
Nothing they said is wrong per se but the cost in time and resources of delivering all of those features is gigantic and we’d have to wait until the very end before we saw even a slight glimmer of that all-important validation.
The problem occurs when we think about what ‘one thing’ is. So let’s change the language we use so that people won’t mind having a tiny subset of features — and it won’t feel like a failure. Let’s build halfthings.
Build a halfthing
A halfthing is:
- so stupidly simple that it looks like we’re just being lazy,
- deliberately featureless so as not to influence feedback or impose our prejudices,
- focussed on the core thing we want to prove about our product,
- releasable to real users.
For our TinyPins project, here’s a proposed halfthing:
A single webpage showing, on a map, the name and location of all visitors.
No signing in or building a network, to invite people just send them the link. No limits on how long to share your location for, just close the page when you want to stop sharing. People can use text messages or phone calls for messaging like they do already. There’s no need to solve every problem — just the most important one.
Rather than a list of features, build a single sentence. Find the thing that you want to validate, and build that first.
If you made bad assumptions, you can quickly pivot and try something else — either way, you’ll learn so much just by getting something in front of people. If users like it but need some other features, you’ll quickly find out about it.
So in a few days, we can get something for people to start playing with. So what next? Well even when we have an existing product, building halves of features works too.
If we decide that we next want to validate the meeting place idea in TinyPins, we just need to find a halfthing that allows us to do so:
Add a button with a `mailto:` that sends us an email from the user with a link to the page, asking for advice on where they could meet.
Rather than building complicated recommendation engines and automated integrations with the Google Places API, we could just simply add a button that allows users to email us and we’ll do the research manually, and reply back with an email.
This solution is not only very easy to implement (it takes about 2 minutes to code this and another two to setup an email account,) it also puts us in direct contact with our users, initiating a real dialogue. We will find out first hand what our users are trying to do with TinyPins, in a way that would otherwise be impossible, and can let that drive what we do next. Imagine if people started emailing asking for details of movies playing nearby instead, or if it was used at Glastonbury for people to figure out the band schedules, who knew right? Nobody did.
If too many people start using it and we can’t cope with demand, we’ve got a great problem on our hands, and a great story to take to our stakeholders.
What is your halfthing?
If you’re en route to a product launch, or are about to get into bed with people on a new project, send them this article and ask them what they think your halfthing is. If it’s too long, or doesn’t get your core idea validated soon, you should pause your project immediately and take a couple of weeks to first build your halfthing.
Tweet me @matryer if you’re struggling to find a halfthing for your project, and we’ll see if we can figure it out together.
