Going Zero to One : A Wanderer’s Notes on Product Research

When was the last time you reached out to a stranger on LinkedIn, hoping to tap into their understanding of an interesting new market? If you’re like many product managers, grown accustomed to leaning on existing customers or internal subject matter experts, that thought just sent a chill down your spine!

But the most interesting new ideas can’t be found within your office walls, they’re out there in the wooly wild of emerging markets.

Developing a new product in an emerging or rapidly-changing market – going zero to one – is dramatically different from building out a mature product or creating something new in a well-understood space. While the core product management skills of research and requirement design are shared in both situations, the importance of open-ended questions, the willingness to discard hypotheses, and to live in uncertainty while constantly experimenting can be so different as to paralyze even the best product manager.

To understand how inventing a zero-to-one product in an emerging space is different from developing for a well-understood market, let’s first talk about repeatability.

Repeatability is what turns a product into a business. The ability to sell what you’ve built to 80% of the prospects you can attract, using only your set of sales playbooks is the catalyst that enables infusion of capital to predictably deliver measured growth.

Late-stage startup development goals – operational mastery of your funnel metrics, pipeline efficiency, customer acquisition cost, cost of goods sold and net retention – are all gated on repeatability. It doesn’t make any sense to talk payback period, unit economics, or EBITA until you have repeatability.

So what’s the relationship between defining your product strategy in your market and achieving repeatability? It’s a sequential relationship, where building and executing your product strategy delivers product-market fit and enables you to start developing sales repeatability, and it is foundational in the lifecycle of a company, particularly in its early stages of growth.

Let’s define our terms.

1. Product-Market Fit (PMF): This refers to the stage where a company has validated that its product or service satisfies a strong demand in a specific target market. It’s the point where customers are not only willing to buy the product but are enthusiastic about it, leading to strong customer retention and organic growth through word-of-mouth referrals. Achieving PMF indicates that the product solves a real problem for a significant portion of the market.

2. Sales Repeatability: Once PMF is established, the next challenge is to build a repeatable and scalable sales process. Sales repeatability means that a company can predictably generate revenue by applying the same sales strategies, tactics, and processes across multiple customers. This involves creating consistent sales methodologies, refining the buyer journey, and ensuring that sales teams can replicate success without needing to reinvent the process for every new lead.

The key relationship attributes between PMF and Sales repeatability are dependency, efficiency, and scaling:

Dependency: Product-market fit is a prerequisite for achieving sales repeatability. Without a clear understanding that the product satisfies a market need, any sales process will likely be inconsistent or fail to scale. PMF ensures that there is demand; sales repeatability ensures that this demand can be systematically addressed and monetized.

Efficiency: Once PMF is attained, it becomes much easier to develop a sales strategy because the value proposition is clear, and customer feedback has validated the product’s relevance. The sales team can then focus on refining the messaging, targeting, and techniques to reach similar customers in a repeatable manner.

Scaling: When both PMF and sales repeatability are present, the company is in a strong position to scale. PMF ensures the product is wanted, and sales repeatability provides the mechanism to efficiently capture that demand on a larger scale, driving revenue growth.

To sum this up: product-market fit is about proving the product’s value, while sales repeatability is about scaling that value in a structured and predictable way.

PMF is essential to success for any product endeavor. This is no different when you’re looking for success in a new or rapidly-changing market – but the difficulty is far higher. Without an established customer base to survey, existing players to study, or even a well-defined market for analysts to report on, first-principles research and the hard work of developing relevant primary sources is a requirement

And a little flailing around on LinkedIn isn’t going to cut it – sorry folks, no shortcuts here!

So here’s a structured yet adaptable approach for developing a new product thesis in a poorly-defined market, given the uncertainties and complexities involved. Let’s outline the key elements for this process:

1. Gather Your Market Insights

Lean on early pioneers: Establish close connections with early adopters in your target space, allowing their feedback to guide initial directions. Engage with them through multiple rounds of discovery to refine your understanding and uncover questions you didn’t initially know to ask. Invest in building quick-and-dirty concepts, experiments, and mockups and orient your feedback processes to suss out the problems that are interesting to solve rather than the specifics of a given solution.

Broaden your research horizon: Recognize the limitations of relying solely on existing customers, as it can create a biased view of the market. To build a balanced picture, expand research to potential customers who aren’t engaged yet. Spend some of your demand generation resources driving traffic to your research programs, and engage with as many relevant people as possible, even if they’re not immediately actionable prospects.

And leverage the discussions that are happening outside of your own activities! Participate in community meetups, in online forums like StackOverflow and Reddit discussions, and at industry events and trade shows. Even industry blog comments can give a broader view of latent needs. Throughout this, be rigorous in your data collection – keep good notes, leverage AI transcription of meetings, link back to discussions, and constantly re-examine both your insights and the audience they’re derived from.

Finally, consider contributions you can make and experiments you can run in your target market, even (maybe especially) if they’re not a product you intend to sell – engaging with a community is much more meaningful if you’re offering to contribute, not just learn.

Scale your research efforts: As the need for quantitative and qualitative supporting data grows, consider formal survey research or UX-focused analysis to capture wider market insights systematically. Forums and conferences are great for conversations, but those anecdotes are not easily subjected to rigorous analysis.

2. Define Your Product Direction

Don’t be afraid to use intuitive decision-making: Base your product’s direction on a combination of intuitive understanding from research and technical discussions with engineering partners. This ensures that the solution aligns both with market needs and technical feasibility. Your target market isn’t going to be good at describing its ideal solution – you’ll need to use your understanding of the problem to invent interesting products, but you also need to stay grounded in technical reality.

Evaluate risks: Each new product involves distinct risks:

– Customer Relevance: Validate that the product concept resonates with a potential customer base. Mitigate the risk of building an exciting solution for a problem that isn’t important through interviews grounded in a prospective purchase.

– Feasibility of New Concepts: For novel or untested ideas, ensure that the team has clarity on the concept, expected outcomes, and technical capability to deliver.

– Resource and Timeline Management: Establish realistic timelines and resources, balancing the anticipated product development time against available bandwidth.

Set tactical milestones: To mitigate the risk of sinking too many resources into an impractical or unattractive product, set measurable milestones, such as early customer pilots, technological proofs-of-concept, or small wins with initial investments that confirm feasibility and value.

3. Set Priorities and Milestones

Establish early momentum: Resist the temptation to complete your product before sending it out into the world – you don’t need a complete solution to get feedback, just the kernel of value that activates your audience. Prioritize deliverables that establish a sense of early progress. Bring together cross-functional teams (product, engineering, design) to align on immediate goals that demonstrate velocity and validate the product concept. Nothing will energize (and validate!) your early work better than getting an early concept into the hands of real users.

Prioritize your roadmap through your vision: A clear north star vision is essential for aligning the roadmap. Establish guiding principles and strategic trade-offs that provide clarity for every roadmap discussion. This shared vision acts as the decision-making anchor and ensures that product decisions stay on course.

Plan collaboratively: Develop the roadmap in consultation with engineering, UX, and business teams:

– Product: Focus on customer and business value.

– UX: Ensure each milestone delivers a cohesive user journey.

– Engineering: Evaluate technical risks, confidence in deliverables, and realistic development timelines.

Communicate with your stakeholders: Regularly present the roadmap to leadership, ensuring alignment. When sharing externally, maintain a consistent narrative that conveys how the roadmap leads to the desired outcomes for customers and stakeholders.

4. Test and Validate

Use early feedback loops: Prioritize early and continuous feedback as a principle. Test hypotheses with users from the start using informal mock-ups, clickable prototypes, or API demonstrations. This allows for rapid learning and iteration, well before reaching a beta stage.

Invest in user behavior analysis: Observe user interactions closely—monitor what users do, identify pain points early, and be ready to adjust based on their success or difficulties.

Manage expectations: As you gather early feedback, control the narrative to avoid misinterpretations or unmet expectations among stakeholders, especially when testing is in ideation stages. A vocal minority can easily kill a seedling product, even over a misunderstanding.

5. Handle Inbound Requests

– Align using your strategy: Treat the roadmap as a living document while maintaining a consistent vision and strategy. Evaluate each inbound request on whether it aligns with this strategic vision, determining if it’s simply a premature idea or if it diverges from strategic priorities altogether.

– Balance customer influence: When handling requests from key customers, weigh their business impact and the potential need for custom work. Consider the future trade-offs, like tech debt, that may arise if requests require substantial customization.

6. Manage Technical Debt

– Understand Long-Term Impact: As a product manager, cultivate awareness of the technical debt implications of certain decisions, particularly custom requests. Often, early decisions have long-term impact on your ability to sustain development. Evaluate if taking on tech debt for one customer aligns with the broader roadmap and, if so, plan for how and when to address it in the future.

Tying it all together

In essence, building a new product for an unclear market involves a flexible approach grounded in deep customer understanding, iterative testing, and a well-communicated strategy. Balancing these elements can help shape a viable product that resonates with a still-emerging market while remaining adaptable to new insights and challenges.

And developing your market and product hypotheses using the knowledge you’ll collect this way is your best shot at finding product / market fit and successful growth. Now get out there and get researching!

Why Dual CTO/CPO Roles Are a Terrible Idea

Yesterday, I had a chat with a recruiter about a hybrid, dual-titled CTO/CPO role. It wasn’t the first time—in the past few months, I’ve spoken with several CEOs and executive recruiters on the hunt for hybrid CMO/CPOs or CTO/CPOs. It’s a growing trend (see here: Leadership Revolution: C-Suites Journey into Hybrid Territory and Combining CTO and CPO Roles).

And it’s a terrible idea.

Why the strong reaction to combining engineering and product or marketing and product into a dual-titled executive seat? I’ve actually worked with and for executives in hybrid roles—a CMO who doubled as CPO, a CTO/CPO, and even a CRO/CMO. None of these setups worked well, and none lasted more than a year before either the executive left or the role devolved back into its original, distinct forms.

Turning that role into a dual-titled mashup

There’s a solid business reason why product, marketing, and engineering need separate leaders—the tension between these roles keeps messaging accurate, roadmaps realistic, and prioritization ruthless. Combine two functions under one leader with a single set of goals, and the balance can easily tip.

You see this in “founder syndrome” when startup CEOs hold onto product ownership for too long. Since the CEO always wins debates, marketing and engineering end up taking a backseat, often to the detriment of the product. Similarly, an engineering leader who also manages product often creates roadmaps that lack ambition and focus too much on technology iteration. A marketing leader who owns product is likely to produce appealing roadmaps that are unachievable or lack a deep understanding of the user.

This isn’t always catastrophic—plenty of healthy organizations have product under engineering or marketing. But the real issue for me is acknowledging the need for a CPO and then turning that role into a dual-titled mashup with another existing role.

What’s the function of a C-level role?

Let’s take a step back. What’s the function of a C-level role? Throughout my career, I’ve seen a common organizational theme: C-level roles are about organizational priorities, giving a function a seat at the table when company strategy and goals are being set. C-level leaders advocate for their function’s needs, commit to goals and metrics, and allocate resources to achieve those goals.

C-level roles are not about promoting a great VP, or indicating membership in an executive staff, or attracting specific talent. Choosing which C-level roles exist in a company is about what priorities are critical to the organization at a given stage of its growth.

And: the typical C-level roles in an organization evolve over time. This can be seen in the rise of the Chief Revenue Officer in the late 2000s (combining new business sales and customer retention), the emergence of the Chief Customer Experience Officer in the early 2010s, and the rise of the Chief Data Officer in the late 2010s (highlighting the critical role of data and intelligence).

When one executive wears two titles, it’s impossible to recreate the healthy tension between two separate roles.

Individual C-level leaders create clear priorities and ownership within the executive team. But when one executive wears two titles, it’s impossible to recreate the healthy tension between two separate roles—one role will always dominate, lacking the balance that discrete leaders provide. It’s like playing solitaire against yourself – and cheating.

Moreover, consider the motivations behind such roles. For a CEO, it might signal the blending of two previously separate positions – although there are better ways to do this. But for the executives advocating for and taking these dual roles, there’s often an undercurrent of resume-building. Scratch the surface, and you’ll find no solid thesis on why the two roles should merge—just a desire to add both titles, like merit badges, to their experience.

In fact, some CEOs have admitted to me that they combined CTO/CPO or CMO/CPO roles because they were struggling to attract top talent. The allure of holding two C-level titles attracts executives eyeing a future CEO role, often from VP-level positions at public companies. The offer of dual titles can be a deciding factor when compensation or company reputation falls short.

There is a natural way to add a healthy product function to marketing or to engineering – that’s what a VP of Product is for.

There’s a legitimate way to merge two functions in the executive team—create a new title and clearly communicate the change in priorities. And there is a natural way to add a healthy product function under marketing or engineering – that’s why you hire a VP of Product under a CMO or CTO. But tacking ‘CPO’ onto an existing role and expecting one person to function effectively in a hybrid capacity is unrealistic.

And – most importantly – it doesn’t work.

Struggling with hiring top-tier product managers? It’s a challenge many of us face.

Making the wrong hire isn’t just a hit to the budget and the calendar—it can shake the very foundation of your product, costing you users, customers, and that all-important product-market fit. But let’s be real, interviewing product managers is a whole different ball game compared to, say, hiring a good Customer Success Manager or a stellar engineer.

Why’s it so tough? Well, for starters, product managers are masters of storytelling. They can spin a yarn that’ll have you nodding along in agreement. But separating the talkers from the doers, especially when it comes to nailing down solid requirements, is a whole other story.

So, here’s a game-changer: a simple test that can weed out the real deal from the smooth talkers.

The need for a reliable testing method

I stumbled upon this gem back in my days at an early-stage startup. We were on a hiring spree for product managers, sifting through five to ten candidates daily. Our interviews covered everything from culture fit to creativity, but we were missing a crucial piece: a way to put their hard skills to the test.

Think about it—would you hire an engineer based solely on their description of coding prowess? Heck no! You’d throw them a practical test to see if they could walk the walk. And that’s exactly what we needed for product management.

Despite the inherently subjective nature of product management, certain core skills—like creating user personas, delineating use cases, and documenting requirements—can be objectively assessed.

Enter the structured assessment framework. We crafted a concise scenario, handed it to candidates before their interview, and invited them to tackle it on a whiteboard during the session. Our focus wasn’t on the perfect solution, but rather on their approach. Could they distill complex requirements? Stay true to the scenario? Navigate the problem-solving journey with finesse?

A self-contained capsule scenario

Picture this: a bite-sized problem that anyone can understand, with multiple solutions that don’t require a PhD in our product space. We’d give this scenario out to candidates a week before their interview, no pre-work required. Then, during the interview, we’d slap it on a whiteboard and say, “Let’s tackle this together.”

Take a look! (Google Docs link)

Given the concise scenario, a candidate should be able to tackle it live without any trouble. Importantly, our focus wasn’t on the perfect solution, but rather on their approach. Could they distill complex requirements? Stay true to the scenario? Navigate the problem-solving journey with finesse? Or did they freeze like a deer in headlights? The key was to see if they could keep it simple, stick to the scenario, and get the job done efficiently.

Evaluating candidate results

This approach gave us invaluable insights. Candidates who breezed through the exercise demonstrated a deep understanding and practical application of product management principles. It wasn’t just about what they delivered, but how they got there.

As we put the test into practice, we noticed a few common candidate stumbling blocks. Surprisingly, quite a few were a bit green when it came to developing requirements—a more common issue than you might imagine! Others dove straight into the weeds, obsessing over intricate details like security and permissions from the get-go. Those candidates routinely ran out of time without making much headway, which was a red flag for us.

A savvy product manager could breeze through the task in under 10 minutes, including all the brainstorming and explaining. If it took them between 30 to 60 minutes, that was still within the ballpark, but it often signaled a hiccup along the way—either forgetting their own process or getting bogged down in a tangent. And those who hit a wall on time? Well, they typically either lacked familiarity with crafting solid requirements or veered way off course early on and never recovered.

The impact of a structured assessment framework for product management

This test has become my touchstone for identifying strong product managers. It gives me a clear-cut way to separate the wheat from the chaff. By providing a reliable metric for assessing candidates’ suitability for the role, it removes one of the big risk factors in product hires, and lets me spend time on the strongest candidates. And its simplicity made it easy for interviewers across the team to adopt, fostering consistency and objectivity in candidate evaluation.

This test dramatically sped up our hiring process, and it enabled us to make same-day decisions on promising candidates. So, if you’re grappling with hiring top-tier product managers, give this approach a shot. Trust me, you won’t be disappointed.

Part I – Structuring the product team

Recently, a young, successful tech company asked me to come up with a product planning model for them. I started out by listing off what was already working for them :

Internal entrepreneurialism
Building projects around small teams of motivated individuals
Dual-tracking : small teams for products and separate ones for shared, core components

Then I listed six key goals that are difficult to achieve when you’re newly successful and growing fast:

Keeping leaders informed of everything that is going on
Getting line-level product managers onto a consistent process
Adjusting top-level strategy based on what is working
Identifying what innovation to nurture among all the activity
Discovering shared components that are in decline
Investing mindfully across short, mid and long-term projects

If we want to add that second category of ideals to the mix, it will help to first take a step back and look at Product Management in general. Continue reading “Part I – Structuring the product team” →

Part II – Implementing a marketplace-style product lifecycle process

In Part I we looked at organization theory, determined that a classic hierarchy wasn’t what we wanted, and discussed what marketplace-style organization model could do for us. So what does this look like in practice? Let me introduce you to the Check-in Meeting.

The Check-in Meeting is a venue for reviewing and socializing relevant information about product development efforts. It takes the form of a recurring meeting on a fixed cadence with a queue of topics in three categories:

Product Plan Review : Present a new project plan or new phase/initiative of an existing project, to propose alignment with an existing strategy and prioritization
Progress to Plan : Measure a project against stated milestones and goals, in order to secure or retain allocated resources
Strategy Review : Periodic review and debate of top-level product strategy among CPO and directors, informed by data from recent PPR and PTP topics.

Continue reading “Part II – Implementing a marketplace-style product lifecycle process” →

Reality-Based Product Management

Product Management theory from an established software development industry leader

Tag: business