DROdio.com
FounderCulture

From Stage Zero to One PMF: Foundational GTM Motions

From

FounderCulture is improving the odds for Founders • Become a Patron to support us.

🚀 Once you've read this, we highly recommend Scaling Your GTM: The Demand / Land / Succeed / Expand Flywheel

Early-stage Founders typically have an idea in their head they want to get out into the world. Figuring out how to get from Stage 0 of PMF (an idea or MVP) to Stage 1 (initial set of happy, referenceable paying customers) as per The Stages of Product/Market Fit

The Stages of Product/Market Fit requires you do a number of things right. Here's a field guide on how to go about getting from 0 to 1 as quickly as possible:

Step 1: Define your anticipated Ideal Customer Profile (ICP) and User, Champion & Buyer Personas.

  • There's only one thing that's almost certain about your answers: They will be wrong. Quite likely very wrong. But you need to have a hypothesis to start testing your ideas & assumptions with, so this is a very important step.
  • Your goal here is to find people you can start talking to that aren't you so you can get data that goes beyond what you think is true.
⚠️ You must learn to differentiate between internal and external signals early in this process. Many Founders fool themselves with internal signals (we're so busy! we're writing so much code! what we have is great!) when what you need is to have a maniacal focus on generating external learnings and wins. More on this at Differentiating "Wins" vs. "Good News" & "Learnings"
  • Let's imagine that you think your nascent product will be best suited for developers to use at mid-market enterprise companies. And you think that DevOps managers will be your champions, and VPs of Eng will be your buyers. Congratulations, you've just defined your first set of users, champions & buyers at your ICP. The next step is to find some of these people to actually talk to.
💡The closer the user is to the buyer, the more efficient your GTM strategy can be (because the user can, for example, pull out a credit card to buy the thing they're using). The farther the two are away, the more you'll have to pursue a heavier middle-out or tops-down strategy (like a CIO buying a platform for the entire org to use). More on this at B2B Sales Motions: Bottoms-Up, Middle-Out, Tops-Down
  • Many Founders — especially technical Founders — will start writing code at this step. We strongly advise against this. At Armory and co-founders did 100 customer persona interviews before writing a single line of code, a process that took several months and resulted in 254 pages of call notes. Without fully understanding exactly what problems people have, how big those problems are, and whether they might pay to solve them, you're focused on the wrong thing if you're already building the solution to an undefined problem.
  • Instead, start using hacks like How FounderCulture Uses Teamable to gain access to your desired personas and start booking meetings

Step 2: Asking The Right Questions to the Right People

  • We recommend you start by focusing on your Champion persona. This is the person who you will need to convince to do your work for you inside their organization. This is the person you will need to get excited about your solution. Without the Champion, there will be no Buyer.
  • The exception to this approach is if you want to focus on a super bottoms-up Product Led Growth (PLG) strategy, where the user is driving adoption almost exclusively. In this case, set your sights on identifying early-adopter users, and then understanding how you can create magical product-driven experiences for those users.
  • Let's imagine you've lined up a series of calls with potential DevOps managers of mid-market enterprises. The next important point is that you do not want to call them to tell them about your solution. You are not in "sell" mode on these calls. You are in "listen and understand" mode. And you are specifically focused on Understanding Pain vs. Offering the Solution.
  • We recommend you book an hour for each call and follow this approach:
  • Intros: Hopefully, you're on the phone with this Champion persona because of a trusted mutual connection. Start by getting the Champion talking. You want to warm them up so they get comfortable. Ask them how they know your mutual connection. See if you can find a few more points of mutual connection. Your initial goal is to get them to open up and relax a bit so you can have a meaningful conversation.
  • Build Credibility: Next, you want to give them a reason to talk to you, and to pour their heart out to you. You want them to realize this call won't be a waste of time for them, because they'll be helping you build the future to (hopefully) solve a problem they have today. Briefly tell them a bit about your background — but just enough to build some credibility. You don't want to spend too much time talking. Something along the lines of we are building some tooling in the devops space, and we've totally been in your shoes. In our last company we had to manage 250 developers across multiple teams that all did things differently etc.
  • Also, tell them what you hope to accomplish on the call. Something like we've got a few ideas on how to solve some big problems in the developer tooling space, and we'd like to understand your pain so we can validate or improve on our approach. We've got some detailed questions for you about how things work today at your company, and then we can share a bit about what we're building to see if you think it could help solve your pain points. You want to offer up a value exchange — they give you their pain, and you might have a solution for that pain. However, remember that this is not a sales call. You're not trying to convince them that you are right. You are here to listen and look for patterns in the pain.
  • Start Broad: Your next goal is to understand what this Champion's biggest pain points are in the problem space you've identified, but without constraining it too much. You might ask some very broad questions like What's the #1 thing keeping you & your team from being more successful right now? or What do you wish someone would build, but hasn't?. If you're lucky, this person might give you some answers that fall squarely in your anticipated problem space. But if they don't, that's also really valuable — either you have the wrong Persona identified (better to find out early!), the wrong ICP (maybe you need to find a bigger — or smaller— company size to target) or the problem you're solving isn't as burning and top-of-mind as you think it is.
  • Hone in: You can gradually hone in by adding modifiers to your questions. For example, since your anticipated problems space is dev tooling you could re-state your question above as What dev tooling do you wish someone would build, but hasn't?.
  • Get Specific on Understanding What Happens Today: The more you can understand exactly how the company is solving for the problem you're building a solution for, the more opportunities you'll uncover to build a better & more scalable alternative. Get specific, again without giving away your proposed solution (yet). How exactly do they work? What tools do they use? What versions? What workflows? Who does what? What systems do they use? What are the problems with those current systems? How much do they cost? Who pays for them? What are the company's strategic initiatives? The department's? Do they use OKRs? If so, how are they performing against those OKRs this quarter? It can be a bit awkward to ask these specific questions, which is why many Founders don't do it. But just think about it this way: Would you rather get good at asking specific questions, or get good at building the wrong things? Asking these questions to uncover pain helps you build the right thing fast, instead of the wrong thing right.
💡 People will always know their pain. And they will think they know the solutions to that pain. Focus on really understanding the pain. Great product development is about translating that pain into a scalable solution that will likely look markedly different from what the person thought the solution was.
  • At this point, you should be at least 30 minutes into your hour-long call — and you've only talked about the Persona's pain. Not the solutions they think would solve for that pain. Nor the solution you think would solve for that pain. You've been purely focused on understanding what's not working today, and how painful it really is for them. Are they going to miss shipping a big deliverable this quarter? Are they worried about getting fired? Are their developers quitting in frustration? Really work to quantify the type & amount of pain they are feeling.
  • Validate Their Pain: It always helps to know you're not alone. To the extent you can, weave things you've heard on other similar calls into this one, to help legitimize the pain they're expressing.
  • Ask How They'd Solve the Pain: Next, you can ask them for their ideas on how they'd solve for the pain they're feeling. Find out if they're actively working on solving that pain. Have them show you how. For example, oftentimes people will use the tools they have at-hand to ameliorate the pain. Maybe they've made a bunch of spreadsheets. Or some janky, brittle automation using a scripted, low-code or no-code solution. Repeat the entire process above with detailed questions to understand exactly what they've done to try to lessen their pain. Find out if there are others in the org that have tried to solve the pain, and book them for calls as well.
  • Bonus: Get an understanding of how much budget there is — or could be — to solve for the expressed pain. It's always easier to (eventually) sell something that replaces existing spend. Try to understand what that spend looks like today.
  • Share Your Ideas: Finally, with just 15 minutes left in the call, you can do the thing you've been dying to do the entire call: Tell them about your awesome idea/MVP/V1 iteration. It's most likely not going to be valuable/helpful for you do this, and it may even be counter-productive, because you haven't yet had time to incorporate their answers from the call into your solution. The best way to work this in would be:
  • Ask questions like If you had a solution that did [feature x] to solve for [problem x] that you mentioned on the call, would that be valuable? where you are tying features in your solution to specific pain points you heard them mention earlier.
  • Say We'd like to incorporate your feedback into our MVP and give you a demo next week, would you be up for giving us feedback on how well it solves for [problems x, y & z] that you mentioned on the call?
💡We've learned that the word interesting is a strong contra-indicator. If you're talking to prospects who tell you that what you're doing is interesting, it means they're not sufficiently convinced that it's compelling. Interesting means " come back to me later when you've figured more things out" whereas compelling means "I need to have this yesterday to solve a very well defined problem."

Step 3: Find Patterns in the Pain

Once you do enough of these calls, you'll start to find patterns in the pain, and you'll also be able to better hone into who your Personas really are. Those patterns will help you prioritize your product roadmap, and as a bonus you'll also know exactly who to go back to once you build those features to beta test them. Many times, the patterns you find will surprise you, which is the entire point of this exercise, and will completely change the trajectory of your company as it matures.

💡A note about fundraising & timing: It's not enough to fundraise based on these patterns of pain. Unless you're a well-known Founder with a past track record of success, you'll need to build a prototype to show some initial traction to solve for that pain. More on this at and MVP vs RAT.

About FounderCulture: Only 1 of every 200 seed-funded startups make it to a $1Bn valuation. FounderCulture exists to improve those odds for Founders worldwide by removing the friction of founding and scaling venture-backed companies. We are building a trusted community to share knowledge with authenticity and vulnerability among Founders. FounderCulture is created by Founders, for Founders. Learn more about FounderCulture:

  • Welcome to FounderCulture
  • Why Founders Need FounderCulture
  • Our Vision, Mission, Values & OKRs

Become a Patron if you'd like to see us create more content like this for Founders:

  • Support FounderCulture: Become a Patron, Buy an NFT or send BTC/ETH .
  • Thank you, FounderCulture Sponsors


Ask me anything