Menu
You don’t have a working beta of your product. You need to validate your value proposition with market feedback to create your first product road map. Here is where you need to engage with Innovators and no other market segment.
<Introduction><Introduction>
Let's assume you just raised your first round of capital (congrats! 🎉 ). You don’t yet have a working beta for USERS to try and now need to validate the value proposition from your pitch deck using market feedback to create your first product roadmap and start building.
This is the time when you need to engage with innovators and no other market segment. This phase typically covers months 1–6 in our 18-month timeline.
There's a good chance that, in your pitch deck, you have a slide or part of your talk track dedicated to explaining who the ICP (ideal customer profile) is for your product. A traditional ICP might look like the following.
Details about your ICP's pain, need, beliefs, etc. are important but missing a lot of the context necessary to clearly distinguish who you should be interviewing as an innovator in order to define your product roadmap. For example, if your ideal USER is a security engineer, the USER who works for a large bank is very different from a USER with the same title working for a Series C startup.
To help you define your target-market segments in enough detail to enable you to focus on the right segment at each phase in your product development, we’ve created this GTM Framework and Market Segments Tool to help you define your early market segments and get your GTM motion going. We’ll revisit this framework as we consider each of the three market segments, but for now we’re focused on innovators.
As you address these questions, you’ll want to consider target companies to work with in each of our three market segments. It’s helpful to dive into Crunchbase or Slintel so that you can develop and refine your hypotheses about which companies make good targets in each segment, but with a focus on the innovator segment at this stage.
Innovators also exist at larger companies in centers of excellence or running specific initiatives within a larger department. Innovators look for opportunities to give feedback to startups, so once you begin outreach, they tend to have a response rate that's higher than average. They also tend to exhibit good career progression in a specific domain (e.g., moving from data scientist to senior data scientist to a director or VP role.) They often post content on LinkedIn or Twitter or engage with the community in their area of expertise.
In addition to private companies, you can also find design partners in public companies (at least one year out from going public). Design partners are similar to innovators but tend to be motivated much more by solving a specific business problem to gain a competitive advantage rather than just a desire to engage with you or the community around new ideas.
Early majority companies tend to be in Series D to at least three years as a public company. This group may ask for customer references, case studies, etc. to justify working with your company since they are naturally risk-averse. They simply want to make incremental, predictable improvements in their workflows.
A USER’s workflow is a series or set of tasks that comprise a key aspect of their job. For example, machine learning (ML) teams have a workflow that includes some combination of these tasks:
Data scientists do much of their work in the Python programming language in Jupyter notebooks or another IDE (integrated development environment) designed for data science. They use Python code libraries and other software tools provided by several of the major enterprise, SaaS, and cloud companies in the space.
Some portions of each task are straightforward for data scientists. Some are not. For example, many data scientists do not know SQL. Therefore, transforming their Python code to make it ready for a production environment for Model Training presents a challenge.
Some ML teams are composed of just data scientists; others include data engineers and ML engineers. Some require collaboration with ops teams in order to make their work accessible for use by the wider company.
There’s a lot to unpack and understand for this workflow just as there is for the workflow of any USER community you target. By going into detail to define your USER’s workflow and specifying the part that you’re disrupting, you "force" your team to do the kind of thinking necessary to begin to really understand your value proposition. You also identify gaps in your understanding of your USER and their pain points. These will bring focus to your conversations with innovators who will help you refine your understanding of your value proposition and help shape your product road map.
Next, we’ll define exactly how you’re disrupting that part of your USER’s workflow.
Once you’re able to articulate what part of your USER's workflow your product disrupts, you’ll need to precisely define your technical innovation and how your product will provide business value. These two together comprise your business case.
When it comes to describing your technical innovation, you can take the slide(s) right from your pitch deck. This is usually an architecture slide or a data-flow slide that summarizes three to four key technical breakthroughs. You'll need to contextualize these by defining how you improve a USER’s day-to-day experience in the part of their workflow you’re targeting.
You’ll also need to translate your technical breakthroughs into business value drivers that BUYERs care about. This doesn’t come naturally to most. One tactic is to keep asking, “so what?” about each technical innovation until you can clearly articulate:
In the diagram above, we’ve outlined the four most common business value drivers used to measure the impact of a new product. Your product must enable a business to achieve at least one of these. Most enable two or more.
Next you’ll add context to your evolving picture of the USER. The goal here is to determine who among potential USERs for your product most acutely experience the pain that your product solves. In order to help optimize for adoption, you’ll also need to consider who enables adoption within the USER’s org and who stands in the way.
To get to this level of detail, you’ll need to dive into when, where, and why a specific USER is the perfect fit for your product. Some questions you’ll want to explore include:
Using questions such as the above, you’ll want to get specific in identifying the context in which your USER works and their current company's journey and then validate this with Innovators and design partners.
Your BUYER is the person who has control over allocating budget to your product and will be the one signing the order form and/or purchase order. For design partners, even if there isn’t a purchase, a BUYER will typically need to approve your partnership.
There are two key aspects to remember for BUYERs:
An enabler might not be involved in the decision-making process, but they enable installation or access to your product. Identifying enablers is especially important if you need access to cloud environments, specific APIs or microservices, security permissions, access to a specific SaaS app, etc. Enablers are often on DevOps teams, infrastructure teams, and security teams.
The main reason design partner and production installs get stuck is due to not supporting enablers. Enablers need documentation to follow and a clearly defined support channel and process by which they can get help from you.
Your primary USER (aka your champion) should help you identify who they will need to involve based on your installation path.
A detractor sees your product as a threat to their current role and the ownership they have of that part of the USER’s workflow. A detractor can also be an individual who prefers a different solution than your product, whether it’s a direct competitor or something they built internally.
Your USER should be able to identify for you who they think could be a detractor and work with you to come up with responses to their objection proactively to neutralize their impact on the installation process or a purchase.
One red flag we get from founders when asking who they compete with is, “No one is doing what we’re doing.” The fact is that few startups are creating a complete paradigm shift. Most are building a significantly better form of an existing workflow, which guarantees competition.
We think about competitors in two camps: direct and indirect. Direct competitors take a similar product approach to solving the same problem you’re targeting, for the same USERs. Indirect competitors are companies whose products can be used to address the problem you’re targeting and for the same USERs, but are not built specifically for that purpose.
For example, one company we’ve recently partnered with in the event management space is Goldcast. They directly compete with companies like Hopin and On24, for the same budget, in a winner-takes-all fashion. Their indirect competitors are companies like Zoom. Zoom isn’t specifically built for the event management part of their USER’s workflow, but their customers are trying to use it for that purpose since they’re already allocating a budget toward it.
The last piece to consider is how you package your product. Decisions around product packaging will get complex as you grow, but in the beginning you want to optimize for the following dimensions:
Once you have an idea of how you want to package, you need to consider what the value equation for your pricing will be. A good place to start is studying what your direct competitors use to determine their pricing (per USER, per use case, flat fee, consumption based, etc.) to determine where you compare and what’s preferred. We'll touch more on packaging and pricing in later sections.
Continue to: Innovator outreach and interview tactics
