It’s been a little over 18 months since Steve quit his day job and ventured out on his own. Even though his savings ran out six months ago, he has hit a comfortable groove using freelance consulting to keep his product development going. He’s come to terms with the fact that bringing his vision to life is going to take its due course, but he’s not in a hurry. Rome, after all, wasn’t built in a day.
It’s a Tuesday morning, and Steve is in line waiting to order his morning coffee before heading to a client site for a meeting. He gets a text message from an old buddy of his:
“Have you seen what Kickster just launched? It’s your idea, Steve!!!”
Steve clicks through the link, scans the page, then goes white…Kickster does look very similar to what he has been working on for the last year and a half. They just got covered by Techcrunch and announced a big fundraise.
He starts feeling sick to his stomach and leaves the coffee shop. He reschedules his client meeting from his car and heads back to his home office instead.
There, he spends the rest of the day poring through Kickster’s site, trying out their app, and searching online for anything he can find on them. After several hours, he concludes that while the idea is similar, Kickster’s implementation is quite different from his.
Steve feels a bit relieved because he believes he still has the more elegant solution. But that relief is only temporary as new anxiety sweeps over him: “What good is a better solution if I launch too late or never get to launch it?”
He needs to kick things back into high gear.
Maybe now he can get the support of his developer friends who failed to see his vision earlier. Or maybe now it would be easier to raise funds from investors?
A million ideas start racing through his head. Where should he start?
He decides to reach out to Mary for advice. Steve used to report to her in his previous startup. Like him, she, too, had taken the severance package after their startup got acquired and then shut down. He had run into her at an event a few months back and learned that she had also started a new company with a few other co-workers. And by all accounts, they seemed to be doing quite well. They already had over 30 employees, paying customers, and venture funding.
He shoots her an email, briefly outlining his situation, and asks to meet for lunch. He gets a near-instant reply:
“Let’s meet for tacos tomorrow at noon — usual spot.”
Steve learns about Minimum Viable Products
Steve gets to the restaurant a few minutes before noon and grabs a quiet table in the back. As he settles in, he notices a text message:
“Sorry, running 10 minutes late — deployment day.”
He takes the extra time to organize his thoughts and doodles out a high-level plan in his journal:
- Secure seed funding.
- Hire three developers.
- Finish and launch the platform in 3 months!
Just then, Mary walks over.
“Sorry for being late, Steve. We have a big rollout this week and have been fighting several production issues all morning. I would normally have rescheduled, but your email sounded urgent. What’s up?”
Steve takes the next 5 minutes to summarize what he’s been up to, the Kickster launch, and his high-level plan for moving forward.
Mary listens patiently and then asks him a simple question:
“Would you rather spend the next six months pitching to investors or pitching to customers?”
She goes on to explain that, even in the best-case scenario, raising money is typically a six months process and a full-time job:
“…during that time, you’re not going to make much progress on the platform. So given your estimates, you’re probably looking at nine months to a launch.”
“I can’t afford to wait nine months!” blurts out Steve.
“Kickster has the first mover advantage. By then, they would have cornered the entire market!”
Mary adds: “I know this will sound cliche, but… competition is a good thing. Competition helps validate a market, and most first movers have a disadvantage, not an advantage. Facebook, Apple, Microsoft, Toyota…I can keep going… weren’t first movers. They were all fast followers.”
Steve isn’t convinced but nods his head anyway.
“Okay…but I still need to launch something sooner than nine months.”
“That, I definitely agree with. Yes, you do.”
“But for that, I need more developers. And I can’t hire more developers without money….”
Mary cuts him off: “You need to get to an MVP that customers want.”
“An MVP?”
“A minimum viable product.”
“Is that like a beta?”
“Sort of…but not really…a minimum viable product is the smallest solution you can build that delivers monetizable value to your customers. I know you have a big platform vision in mind, but customers don’t care about platforms. At least, not at the beginning… They care about solutions that solve their immediate problems. You need to find the smallest solution that solves a big enough customer problem and deliver that.”
Just then, Mary’s phone goes off, and she glances at the screen.
“Sorry, I’m needed back at the office. My best advice for the moment is to read up on everything you can on MVP. Investors today don’t fund ideas or product development but traction. And you need customers to demonstrate traction.”
Steve interjects: “How much traction is enough?”
“If you can demonstrate any traction at all, it sets you apart from the pack. That’s what we did before we spoke to any investors. Having just five paying customers gave us leverage and completely changed the dynamics of fundraising for us. Today, we have ten times that number, but without those first five out, pitch would have just been a bunch of promises. Let’s meet again once you have defined your MVP.”
Steve thanks Mary for her time as she takes one last bite of her lunch and then storms out of the restaurant.
Three weeks later…
It’s been three weeks to the day since Steve’s meeting with Mary. He’s meeting with her again to give her an update.
“I followed your advice. I read up on MVPs, and since I had already built out quite a bit of the product, I was able to launch my MVP within a week…but I don’t think it’s working. I’ve got many users signing up every day, which is great, but no one has upgraded yet, and retention is quite low — most users never come back after the first day. I’ve been running many A/B tests and even pivoted a few times. I’ve concluded that my MVP isn’t good enough. The product is still missing several core features, and I plan to build those next.”
“Let’s back up a bit…Who are these users? Where are they coming from?” Mary asks.
“I announced my product launch in a few online communities, like Product Hunt and Hacker News. That announcement generated some buzz. Some of the traffic is still coming from there. The rest are coming from online ads. I set up a small budget of $10/day.”
“Okay. And who are these users? Have you talked to them?”
Steve looked a bit surprised. “Talked to them? No. But I’ve been measuring everything they do use analytics. That’s how I know retention is low.”
“I see… we made a similar mistake after we launched our MVP. We stopped talking to our customers and relied solely on metrics to guide us. The problem with metrics is that they can only tell you what’s going wrong but not why. We kept guessing what was going wrong, but nothing we did worked. When we started talking to our customers again, we could truly understand why things weren’t working and turn things around. You have to keep talking to your users, Steve.”
Steve cleared his throat. “Keep talking to my users? I’ve never talked to any of them.”
It was now Mary’s turn to look confused. “Huh? Then, how did you define your MVP?”
“Well, I had built up so much of the platform already that I could quickly launch a small application that showcased the platform's power. You said I needed to ship something. Isn’t the premise of the MVP to rush to ship a first release, which kicks off the learning cycle… then use fast experiments to iterate and refine the product?”
Mary sighs. “Sorry, Steve, I should have warned you that MVP is quite a loaded term with many different definitions and approaches out there. Yes, a lot of people subscribe to that approach. And to be fair, it’s still a better approach than spending a year building out a more complete product — only to find out that you’ve overbuilt or, worse, built something nobody wants.”
Mary notices that Steve blushes a bit at her last comment but chooses to ignore it and goes on:
“But, simply throwing your best guess at a solution, no matter how small, over the fence, and calling that an MVP doesn’t guarantee any better results.”
“Doesn’t the Build/Measure/Learn loop help to iterate and refine the MVP?” Steve asks.
“In theory, yes, but a lot of teams get stuck. Think of the Build/Measure/Learn loop as a fast idea validator. If you put a reasonably good idea in AND manage to attract early adopters, it is possible to iterate and refine your MVP as you describe. But if you start with a bad idea, all you learn is that your idea sucks. And then you’re stuck.”
“Why is that?” Steve asks.
“Because customers today have lots of choices. If your MVP fails to resonate with them, they don’t turn into testers and patiently deliver you feedback on how to improve your product… they leave — a lot like your low retention users. You are then left guessing why things aren’t working, which kicks off the search for the mythical killer feature — the one that always feels like it’s just around the corner. Sometimes you get a lucky break, but more often than not, you find yourself going around in circles, trying out one idea after another, but are never able to break through.”
Steve’s eyes widen as Mary just succinctly summarizes his situation. He then asks her the obvious question: “If success is predicated on the quality of the starting idea, how does one start with a reasonably good idea?”
“That is the right question, Steve. You do that by focusing on problems before solutions. Today's challenge isn’t building more product, but uncovering what to build.”
A puzzled look comes over Steve, so Mary adds:
“Think of it this way… starting with a solution is like building a key without a door. Sure, you can build great-looking keys quickly, but then you spend the rest of the time searching for the right doors to open. You might get lucky or brute force your way in, but where you end up is usually not where you expected to be… If you flip this around and start with doors, or problems worth solving, then key building becomes a lot easier, and you start building keys to doors that actually take you places.”
“And, there is a process for doing this?” Steve inquires.
“Yes. I was hoping you’d find that in your research on MVP. We didn’t start with building an MVP in our startup but an offer. We first sketched out several variants of our idea on a Lean Canvas which helped us identify and home several promising customer-problem-solution possibilities. We then set up some two dozen customer interviews to validate our customer and problem assumptions. Once we did that, defining the solution was a piece of cake. But even then, we didn’t rush to build out an MVP. We built a demo instead and assembled an offer that we delivered to prospects over many more interviews. We started building out the MVP when we got enough customers to buy into our offer. What we eventually built looked very different from what we thought we’d build.”
“Ah, so that’s what you meant the last time by ‘define’ an MVP?”
“Exactly. You raise your odds of success significantly by spending the requisite time first defining the MVP, then validating it using an offer before building it. Think of it as Demo-Sell-Build versus the more traditional Build-Demo-Sell approach.”
“And how long did all of this take you? It seems like a lot of steps.”
“It took us about eight weeks to go from idea to problem/solution fit. And yes, there are more steps than simply rushing to build an MVP, but if you follow the process and stay disciplined, you end up with a mafia offer.”
“A mafia offer?”
“Yes. An offer your customers cannot refuse. Not because you stronghold them but because it’s too good to turn down. Your solution fits their problem like a glove. At the end of the eight weeks, we ended up with five paying customers pushing us to deliver the MVP quickly versus the other way around.”
“Hmm…This is a very different approach to product development than I’m used to, but I’m starting to see the logic behind it. I still have a hundred tactical questions on how actually to do any of this. How do get users to talk to you? How many people do you talk to? What do you say to them? You’ve been very generous with your time, but can you guide me a little further.”
“Definitely, Steve. This process, like any, has its fair share of sand traps and pitfalls. The biggest one is our own bias or love for our solution. We selectively, and even unconsciously, choose only to consider what justifies building the solution we’ve already envisioned. Shifting to a problem-first mindset sounds simple, but it isn’t easy.”
“Are there tools or resources you can point me to?” Steve asks.
“Yes, I’ll send you a list of resources, tools, and actual customer interview scripts we used and continue to use to train our team. Uncovering problems worth solving isn’t limited to just the MVP phase… it’s key for everything that comes next also. I’ll warn you that this will feel a bit weird and even uncomfortable at first. The key is to be patient, follow the process, and the results will come.”
“At this point, I’ve spent 18 months doing things my way, and it hasn’t worked. I’m open to trying, no testing, anything”.
Mary smiles. “Great — Let’s plan on talking again in 8 weeks… or less.”
.
.
TO BE CONTINUED…
See how Steve’s search for Problem/Solution Fit turns out in the next episode.
.
.
