Minimal to Magical with Hero Features
For as long as we can remember in tech, we’ve been rooting for the fast movers that break stuff and go even faster. That mantra has been taken to heart by many founders as the route to take when taking a product to market. For some weird reason, this has been taken to the extreme, and launching a new product is only a success when it has minimal features and is shipped sooner rather than later because that is where you learn. Sure, that’s one side of things.
The problem with speed for speed’s sake
Look. I’m not saying speed and pace are wrong; I even believe that when orchestrated into momentum, it’s the most powerful force one can feel in entrepreneurship. But it doesn’t come easy, and it for sure as hell doesn’t let itself be forced by half-assed work that gets out the door.
When software was complex to build and even harder to ship, it was surely a huge milestone to have the first release out there. It hasn’t been hard for a long time.
The lean startup conundrum
Let’s double-click a bit further into the launch-as-fast-as-possible movement, the lean startup groupies. Find a niche as small as possible and launch something just on the verge of viable (or valuable, etc.), and with that, start a build-measure-learn loop. When executed with military precision, this is one of the best ways to build with potential customers, but guess what, it rarely is; wait, never is. Not because this methodology doesn’t work but because it always seems to translate to building the very boring features first so that the problem can be solved and then iterating with the customer until the product gets good enough someone is willing to pay for it.
The route to paradise
Sure, sure, when corporate and time to burn, this will work for some. But in all reality, tech should be used to solve hard problems in a magical and effortless experience. Ok, one more: from a founder’s perspective, the MVP/ BML/lean-startup way of working might kill more creativity than it ever brought to the table.
The route to paradise is one with magical momentum. Let me explain…
At Builders, we’re known for our models and playbooks on validating and creating products and companies. This is not because the notion pages are riddled with knowledge no one else knows about; to be honest, most founders, at some point, find it restrictive because of the simplicity of it. The real power of these models and books lies in the possibility of updating these with learning every company creation cycle.
Redefining MVPs and VPs
And even we, for as long as I can remember, were building what most call MVPs at the end of validation. To us, that says minimal viable product, not valuable; wait, even valuable and minimal don’t work here. Again, the meaning of MVP seems to mean something different for everybody; that really doesn’t work. How can we improve on something that has such a different meaning for everybody, even the potential customers we talk to?
So, during the first, let’s say, ten weeks of validating a business case with co-founders, this wording doesn’t even come to the table. Rather, we spend serious time understanding the voice of customers and the pain they experience due to the problem we aim to address. During this process, we validate the biggest problems and transition into solution validation without ever talking about the minimal way it can be solved. Rather, we go the extreme other route.
Rather, we go the extreme other route.
The ironman hero features
A painful problem should be solved with magic or not at all; sure, a 10% relief of pain helps for now, but we’re still hurting so much that our willingness to change (pay) is not affected nearly enough. So when talking to at least 40–80 potential customers, we’re not proposing small fixes or simply asking for the wanted solution (need a car, not a faster horse). Instead, we ask the potential customer to dream bigger with us: “What if your entire job for the year is done when you get into the office at the start of the year? What happened, and what do you see to monitor the progress of whatever happened?”
This question almost always gets replied with, “No, that can’t be done. You can’t build that.” Hold up! Why not? What’s the (real) problem, then? What’s the job that has to be done that apparently you believe is so hard it can’t be done? Ok, go one more time; just assume we’re in a movie, and movie AI is solving the issues for you. Again, what happened, and what are you looking at to monitor progress? This is where the magic happens.
“Just assume we’re in a movie”
Designing solutions around hero features
At this point, you should get a perfect explanation of what we call a hero feature that would change that person’s life and, when framed well, many other lives.
I can already hear the naysayers: “Yeah, great Mike, but why would I follow this route? We should be able to deliver as fast as possible to get paid”. I know; that used to be true. But today, no one is paying for a crap MVP version; you need to bring the magic, Mike.
In a perfect world, you’ve unravelled an aching pain that should be addressed with a set of hero features to match them up with. Let me be clear: that doesn’t mean one should not build as compactly as possible. The best feature is still no feature at all (thanks Elon).
During calls with potential customers, one should vividly test different bundles of hero features that solve 90% of the pain experienced. Yep, the other 10% can be handled by those MVP builders.
Willingness to pay
Now, we understand that this way of building a product will take way longer than the MVP route, so how do we measure willingness to pay, and how do we co-create the product with a bunch of design partners?
After validating the hero features that solve most of the pain, it’s time to get some actual signatures on paper from the first customers. And the learning here is as simple as it gets: when building an MVP and asking for feedback, you’re basically asking, “What does this screen need? What features can you come up with, dear valued customer?” That’s just too old school. Nobody has the time for that, and unfortunately, like House MD said, everybody lies. And you know when they politely lie the most? When getting asked for an opinion on something, they don’t really know what to do with it and don’t know what to answer. That brings you back to square one in validation land. We just spent months doing that; no thanks for now.
领英推荐
Hero feature feedback
As an alternative, why not ask this: “Hey, customer, we talked about the two hero features that solve those three very painful problems. Is anything new on the horizon? Pain still there? Did the pills help? No? Still painful?” Good. “Ok, so here’s a high-fidelity design of the hero feature that helps you monitor progress once the magic happens.” Freaking wonderful. “Does it do it this and that way?”
Did the pills help? No? Still painful?
See the difference? There are a few nuggets here; if you didn’t think of how to solve it, the customer will now give you breadcrumbs, and the mind goes into what else is possible!? This, only this, is where you want the customer to be… amazed and excited about what might come and how it can lighten the burden. Do you think an MVP that just horizontally touches the first steps will do that? No, it will definitely will not.
Turbo, supercharger and plaid prototypes
Of course, this will not be enough to get an early customer to sign a deal with you, and most of our design partners don’t end up being early customers (check out this great article from a16z). I am not saying they will never be, but they are not the first movers — those we have to convince with one more ace up our sleeves.
Due to the CTO residency at Builders, there’s plenty of firepower and appetite to explore and find the boundaries of technology. So, the final pièce de résistance here is being ready for the question that always comes: “But you can’t do this, right? This can’t be built in the timeframe that keeps momentum!?”
But you can’t do this, right?
Well, yes, we can. If there’s one thing that GPT turbos, supercharges, lightning strikes, plaid modes, or whatever have changed, it’s our ability to show technical proof that hard problems can be solved. With these turbos, we don’t do all the magic ourselves but rather ‘pay’ an AI/LLM engine to do the math and magic for us. What?! Yes, of course, you can clank a dataset into an LLM and get more than great results back. Expensive? Yes. Impressive, heck yes!
So, to the question, “This can’t be built, right?” we load up a prototype showing we can deliver on the promise. The ‘only’ thing we must do afterwards is make it less expensive to run. ;)
Skipping the boring stuff
This does a few very important things. It starts with the endgame in mind, showing what the customer is actually buying. And it skips all the boring stuff of looking at designed database screens that might need a new coloured button. Who cares what colour the time machine is? It’s a time machine, and the experience itself is worth every penny. And that’s what we’re looking for.
The hero feature approach ensures that we don’t just alleviate pain but create magical solutions that deliver exceptional value.
At the end of this process, we have very high-fidelity designs for all hero features and have designed a product around that. We call this bundle the first version (bye MVP). Plus, we show our technical ability with the prototype, and whenever the question comes up, “Can we do that?” we go back and fine-tune the prototype.
Falcon rocket engines or no launch.
Lastly, we frame the prototype more as an engine or brain of the product, opening the mind to other possibilities of what the engine could do. This also means that the CTO needs to understand we’re building an engine that needs to be alive; its inputs are ever-changing, and its outputs as well. The core, though, is a super-powered version of a role within an organization. Some call it assistants; others oversaturated algorithms; it doesn't matter. It brings back the power to showcase how far one can go with the tech without the constraints of a design brief.
Here's to returning to the skunk works era, space races, and supersonic travelling. Why? Because we can; that’s why.
With these three things, one can keep focusing on the pain relief, keep the magic alive, show early traction and prove willingness to pay because, with this, we sign the first customers.
Own the endgame
Ok, You still want to go the MVP route? Be my guest. But let’s remember the feedback on your MVP is just a customer trying to give feedback on its way to the hero feature.
Why not start with the endgame and fill in the missing pieces yourself to keep the momentum high? Now, let's build the rocket and go to Mars already.
Cheers. Your friends at Builders ????
ps. Soul searching for that CTO and co-founder, reach out here.
Building startups from scratch
4 个月Own the endgame!
Helping founders leverage AI-powered systems to unlock growth — w/out the typical overhead costs. Open to W2 & 1099 roles
4 个月Michael van Lier True innovation means embracing bold ideas, not just incremental updates. Soon majority of SaaS will offer productized services to increase their customer lifetime value. With nocode tools and AI automation software, the playing field is leveled!