What does it mean to talk to customers and validate your ideas?

What does it mean to talk to customers and validate your ideas?

You talk to customers and other stakeholders to...

a) Collect ideas/feedback about new features or in response to early prototypes

b) Interpret and digest the feedback into the strategy, architecture, and design of the ideal product vision

However, be careful.

Digesting feedback does not mean accepting all feedback.

Instead, it's really about...

a) Listening to the underlying truth/pain/problem of what's being said

b) Deciding if what you hear is 1. a real problem, 2. meaningfully affects PMF, 3. something that's on-strategy/within scope to solve

If the above is true... then it's essential that the feedback is translated into a minimal set of concepts/features/ideas across the various phases and features of the product strategy and roadmap.

In other words, you don't collect feedback and execute. Incredible taste, judgment, and craft must be involved.

Also, remember, the ultimate validation is putting things in front of people and seeing if they use it. Everything other than that is subject to a LOT of noise from stakeholders trying to be...

a) Smart

b) Helpful

c) Confused

The problem rabbit hole

The problem you’re working on goes way deeper and has many more exciting agencies that you first realized.

This is likely true of almost every problem and startup opportunity, ever.

The challenge is that a lack of focus blinds you to this fact. You end up being too busy dealing with the obvious and distracted by the superfluous.

When you truly focus, though, the beautiful and maddening complexity starts to reveal itself. Along with the opportunity found within.

That’s when the fun REALLY begins.

That’s when becoming a monopoly in your niche (and massive scale) becomes possible.

#startups #scaleups #productstrategy #productmanagement #focus #scale

You've got a great strategy - problem solved!

I'm reminded almost every day just how critical a sustained engagement in the execution details over time is to my advisory work.

We can develop an incredible strategy. We can discuss and establish key principles, structure and vision. We can develop a detailed long-term product design - but every single meeting and every single week involves game-changing decisions that can help individuals and teams...

1. Learn how to act in new and more effective ways

2. Avoid strategy drift and reversion to the mean

3. Minimize or eliminate hedging and debate

4. Imagine and communicate a vivid and exciting ideal

5. Execute each detail as brilliantly as possible

6. Fast-forward everything to the best, boldest future

It's harder, more detailed work. But it's so rewarding and essential.

It can feel easy or inevitable once the strategy is crafted. But it can actually be deceptively harder than the strategy development.

It can feel incremental. But it's actually game-changing and the critical way to avoid failure.

Domain Experts are often not the right people to innovate and disrupt their own domain.

Domain Experts are often not the right people to innovate and disrupt their own domain.

Rethinking overcomplicated systems, processes, industries, and disciplines often requires a fresh pair of eyes, a learner mindset, a willingness to ask "dumb" questions, and excellent craft.

Experienced product managers, product marketing managers, and product designers with this kind of fresh perspective can often spot unnecessary jargon, unhelpful mental models, and mismatched categorizations a mile away.

Simplifying and clarifying these complexities is often at the heart of eliminating inefficiency, waste, and pain. Eliminating inefficiency, waste, and pain is at the heart of innovation and disruption.

So, when thinking about hiring PMs, PMMs, and designers - not only is prior experience in your domain not necessarily important, but it can actually work against their success.

Instead, a) look for craftspeople with incredible taste, judgment, intuition, and process b) pair them up with domain experts, and watch the magic happen.

Graceful Degradation - The secret to grace under fire

Graceful degradation can be a highly effective strategy across multiple systems and decisions in a world-class company.

A graceful degradation is when you attempt to execute the best/ideal option; if you fail, you fall back to the next best option. You repeat down the stack ranked options.

The intent is to attempt to execute the best possible option at all times - while always having a backup plan.

Don’t skip steps, or you are typically acting in a sub-optimal way - by definition.

Here are just a few examples of the graceful degradation heuristics I use…

💡Improving user experiences

• Improve the visual metaphor

• Improve the affordances

• Improve the word choice/copy

• Short in-line explainers

• Clear and instructive empty states

• Coach marks/first-time walkthroughs

• Embedded video tutorials on empty states

• In-line help chat (with AI first tier)

• Documentation center

• Self-serve pre-recorded training programs

• Live training programs lead by people

💡Dealing with regulatory constraints

• Figure out the ideal, ethical, user-centric approach

• Minimize exposure to regulatory regimes through a clear separation of concerns/jobs to be done

• Add concise disclaimers to further carve out or skirt around regulatory regimes

• Make minimal adjustments to words to further adjust interpretation (without creating excessive vagueness or confusion for UX)

• Engage with regulators to make a case for the value and intent of your product

• Make compromises to comply

💡 System uptime

• Design systems to be fault-tolerant, scalable and self-monitoring

• Isolate features and systems so that they fail independently

• Attempt to establish an “active-active” production environment so that there is no downtime between production and backup

• Have great downtime messages and outage tracking

• Ensure smooth downtime recovery tools exist

• Ensure disaster recovery processes exist

💡Cross-Squad Collaboration

• Squad missions are designed, staffed, and empowered to act independently

• Squads rely on other squad’s pre-built extensible services to configure or extend for their purposes

• Squads ask other squads to add essential changes to their roadmaps

• Squads do the work themselves with validation from other squad

As a PM, your exec team is confusing the hell out of you!

As a PM, your exec team is confusing the hell out of you!

They each give you different perspectives and priorities.

• CRO is demanding more short-term wins

• CMO is demanding more sexy features

• CTO is demanding more time to pay off technical debt

• CFO is demanding that you spend less money

While a well-aligned executive team (and business strategy) is essential, the various perspectives and short-term priorities of each function will NEVER be fully aligned. This is not a bug in the system. This is a feature of cross-functional teams and the essential problem and opportunity of Product Management.

Your job as a world-class PM in a product-led org is to triangulate the truth based on all available data and first principles to make the final call.

So don't get frustrated. Don't feel like your company is dysfunctional. Don't throw in the towel.

Embrace the different perspectives, craft an incredible roadmap, socialize and align everyone, and lead your team to success.

Your ego is getting in the way of Product Market Fit and startup success.

When developing your product roadmap, it's so so easy to let ego get in the way of making good decisions.

Founders and product managers will often...

1. Fail to ship something concrete, narrow, and specific quickly - instead, their their ego might lead them to worry that their first version seems too simple and embarrassing compared to their full vision.

2. Fail to use simple, human language and metaphors - instead, their ego might lead them to use technical jargon and domain dogma to prove to their peers and colleagues that they know what they're talking about.

3. Fail to build something technically pragmatic and straightforward - instead, their ego might lead them to use unnecessarily advanced technologies and techniques to satisfy their curiosity and/or prove they can do hard things.

4. Fail to focus on product details and the unglamorous work of grinding until their product works - instead, their ego might lead them to believe the details are beneath them and/or that sexy announcements, academic validation, or other ego-stroking distractions are more important.

5. Fail to maintain a lean team and processes - instead, their ego might lead them to over-build their team and processes. to compensate for imposter syndrome and make them feel like they're doing "big boy business".

6. Fail to take maximum accountability for the problems in the business and quickly act to fix them - instead, their ego will block honest self-reflection and lead them to blame their team, VCs and others.

7. Fail to ask for help from mentors and advisors - instead, their ego tells them that “I got this”.

In short, rather than focusing on solving problems and creating user value, they focus on satisfying or protecting their ego from harsh judgment from users, industry peers, or even competitors.

Set aside your ego and focus on your empathy. Empathy for user pain, inefficiency, and waste. Solve problems.

There are two methodologies for deploying capital

There are two methodologies for deploying capital

1. Buying time

2. Buying impact

I’d choose the second one almost every time.

If you can spend a little more to save a bunch of time and increase the probability of a big impact that is far more valuable then spending less and buying yourself more time floundering in mediocrity.

#consultingconvos #businessstrategy #runway #startups #scaleups #startupsnippets

Fear is dangerous

Be careful of founders who are afraid and come from a place of scarcity.

The first job of a founder is to believe.

Their next job is to make others believe.

Their third job is to help everyone do their best work to make their belief true and real.

#startups #founders #fear #faith #scaleups #consultingconvos #startupsnippets

Your argument isn’t where you think it is

Whenever there’s endless debate, indecision and constant relitgation, it’s so so incredibly important to go upstream to examine (and make explicit) first principles, assumptions and use-cases/personas.

If done properly, many downstream disagreements dissolve away.

But it’s not enough to examine them - they must be documented into a compelling narrative and used to…

a) Onboard all new stakeholders

b) Remind and realign all stakeholders when (not if) debates reemerge.

#startups #scaleups #productmanagement #strategy #alignment #management

My Trick Interview Question when hiring PMs and CPOs

I often work closely with companies transitioning to or strengthening their culture to product-led principles and ways of working.

Typically, I help them understand the need for transition, its implications, and the very messy details of making the transition successfully.

Occasionally I also step in as the interim Chief Product Officer, preparing the ground for permanent hires.

An essential part of my job is to help build and refine the product org, which includes interviewing Product Managers, Senior PMs, and CPO candidates.

To test the level to which they've truly internalized the concept of product-led ways of working, I will regularly ask the following question:

"Enterprise sales and large partnerships can often create a lot of thrash for R&D teams. They often come with a diverse range of feature requests, demands, and even contractual obligations that can derail roadmaps. How do you think about minimizing or even mitigating this kind of thrash?"

Many fall back on a standard answer: Maintaining strong relationships, regularly meeting with sales, and proactively understanding customer needs to manage requests effectively.

This is a good answer.

But it's essentially wrong for a product-led company.

A good product leader at a product-led company does not MANAGE inbound requests from Sales and Partnerships - hoping to effectively build what's been sold in the most efficient and generalized way.

A good product leader at a product-led company CONTROLS inbound requests by ensuring that the Sales and Partnerships teams are selling the product they're actually building.

They ensure that sales and partnership activities align with the existing product strategy and roadmap, not the other way around. This involves defining the right customer and partner profiles, specifying specific use cases, crafting a forward-looking roadmap, and equipping the sales team to attract the right kind of clients for their current product, not hypothetical future versions.

It's rare for candidates to nail this perspective, but when they do, it's a strong indicator of their fit for a product-led company, especially for senior roles.

The two hardest problems

Engineers often joke that there are only two intractable problems in engineering…

1. Naming things

2. Off by one errors

If you know anything about engineering, you know that this isn’t far from the truth.

However, the truth is also that…

Oftentimes, half the battle for business and product leadership can be disambiguating and naming things well.

Names are very, very powerful.

Obviously, they are essential to creating easy symbolic handles that people can use to refer to complex concepts or objects quickly.

However, names, if used precisely, can be far more potent than that. They can also be used to…

1. Clarify the utility of a concept or entity

E.g. Movie Search Page

2. Clarify the distinguishing characteristics of the given concept or entity from other concepts or utilities (particularly those that could be confused or conflated together)

E.g. General Movie discovery vs Movie Search

3. Motivate and animate everyone toward a shared vision

E.g. Movie Search 2.0 - Featuring Next-Gen Ranking

4. Imply a namespace for adjacent concepts that fit together - helping to map the concept space

E.g. Movie Search, Movie Recommendations, Movie Rankings

5. Help drive important and implicit understanding in the problem domain

E.g. I never mentioned the company I'm referring to in the examples, but I bet you could guess which one would have such features/concepts in their product.

These few examples clearly show that naming things carefully can be a superpower for product and business leaders. It can be a key technique to accelerate everything from internal discussions, consensus building, and team alignment to external product marketing and sales.

What’s the secret to startup success?

The formula for a successful startup is relatively easy to describe but almost impossible to do.

1. Solve real problems for real people

2. Deliver it at massive scale

3. Find a way to do it profitably

In that order.

Remove anyone and anything that’s distracting you from this list or unable to contribute to it effectively.

Fine and hold onto anyone helping you execute the list more quickly and/or more effectively for dear life. Do whatever it takes to retain, motivate and align them.

The rest is noise.

My Product Decision-making Principles

Idealists are the ones who change the world.

Figure out the ideal and work backward. Don’t pre-compromise yourself before you even get started just because of perceived limitations of scope/time/cost. You can (and must) slice your ideal into thin slices and do the hard work of pushing back on constraints to get to where you're going in iterations.

Come for the tool, stay for the network.

It’s rare to build a marketplace/network/flywheel without first building a killer single-player experience that works on its own terms. Once you’ve cracked the code on single-player, adding a flywheel is almost mandatory. Find one.

Personas and priorities mitigate ocean boiling.

Everyone wants something different. You can’t make everyone happy, or you’ll just be boiling the ocean. The question is NOT “is this a good idea” or “is this a great opportunity” The question “is what do OUR users want” and “is this an opportunity to hit OUR north star metric”? We prioritize carefully in that context using either…

a) Bottleneck Prioritization: What is the #1 reason more people are not more successful more often with our product RIGHT NOW? (great for products with existing usage).

b) Yellow Brick Road Prioritization: What is the journey users are on and how do we ensure that it is as smooth as possible for as long as possible (leaning on sunk cost to keep them going) (Great for products that are new and incomplete).

Eat your vegetables.

As above - make the thing you have work before getting distracted by shiny objects and second or third-order innovation.

Nothing is free.

There’s no such thing as “just adding a checkbox” or “toggling on a new feature.” Every single thing you add to the product affects the journey, its overall story, customer support, tech debt, maintenance, etc. Every single thing must meet the standard of personas and priorities.

Ignore your engineers (and other constraints).

If Elon Musk can launch a rocket into space and have it flip onto its ass and land on a small platform in the middle of the ocean, your team can add that button to your SaaS product. First, figure out what you want (the ideal) before letting engineers (or anyone else) deflect and distract you with technical realities/scoping.

The customer is almost never right.

Users and customers don’t know what they want, and they don’t even know what’s possible. They certainly don’t know what you’re trying to build, and they may not even be the right kind of user or customer for you.

Stop asking them and stop listening to them. Triangulate the truth at the intersection of your strategy and the pain points of your overall target persona. Prioritize based on all of the above.

Alignment is traction.

Almost every decision has upstream and downstream effects on your product, customer journey, and team. Ensure that implications across all dimensions (e.g., ads, marketing, pricing, onboarding, product, offboarding, customer support, etc.) are considered and implemented in alignment.

The funnel is your friend.

Where are people dropping off, and why? Fix it.

Data is deceiving.

Survivorship bias, recency bias, interpretation errors, and other data-related biases can make data very distracting. The map is not the terrain. Set your destination, lift your eyes up from the GPS, and look at the road. Use common sense.

Related: Your OKRs are irrelevant if you’ve realized something else matters more to the business. Throw them out and re-write them mid-cycle if you have to.

Say NO more.

It feels surprisingly good, and it’s the only way to focus.

Say YES more.

Indecision and fear are killing you - bias toward action and get shit done.

A clear vision makes decisions WAY easier.

You don’t need to say NO so much if people (internal and external) already know what you’re doing and why. It also animates, motivates, and aligns all stakeholders when they’re making decisions.

God is in the details.

Pixels, words, mental models, precise product requirements, and more matter a LOT. WAY More than you’d imagine. Get them right. Be precise. Be intentional.

There are exceptions to every rule.

Wisdom is knowledge in context.

There’s a contradicting bit of advice for everything.

Knowing WHICH rules/advice/strategy to apply WHEN and WHY to break the rules is true wisdom.

You can’t learn this from podcasts, blog posts, books, or silly principles lists like this one :)

"Focus" doesn't mean what you think it means.

Often times when I talk to founders who think they are "focused" on "one thing" when what they've actually done is "Conflation".

Conflation, of course, is confusing multiple things together (customer personas, problems, messages).

What they've done, in this case, is to sweep all their unfocused activity under one "rug" or category to make it look tidy.

This just makes it more difficult to design a great product, develop great product marketing messages, and go to market effectively.

The exact OPPOSITE goals and outcomes of real focus.

Focus actually requires a clear and precise definition of things and pursuing each thing one at a time.

This is fairly common advice - but here's where it gets more interesting...

It is WAY better to have MULTIPLE narrowly defined focus areas than ONE focus area that is rooted in conflation.

So don't sweep your distractions under the rug.

Be honest about the nature and number of your precisely defined focus areas AND make an intentional choice to focus on one or more things at a time (if that's what you feel compelled to do).

Want to 10x your team's productivity?

You will be blown away by how...

1. Clear roles

2. Clear ways of working

3. Clear business context

4. Competent people (hiring better)

5. Competent management (better leaders and leadership principles)

6. Dedicated resources

Will RADICALLY improve the efficiency by which you deploy capital and the speed by which you make a real impact on the market.

Stop wasting time - do the hard work and spend the right money to improve your team structure and composition.

Doing any less is incompetence and malpractice of leadership.

Your inaction is killing your company!

Does your company spend countless hours, days, weeks, or even months debating topics?

Does building consensus between key stakeholders feel like pulling teeth?

Does consensus feel temporary and easily dissolve as soon as action is required or as some time passes?

Does it feel like there are just too many moving parts, complex interacting components, and not enough resources to go around?

Many of these things are rooted in fundamental problems like business strategic clarity, product strategy clarity, high-quality senior leadership, and more.

But it's also rooted in the absence of a key cultural trait - "Bias toward action."

Everyone at your company should feel a lots of discomfort if they're not "moving fast and breaking things".

This phrase has lost favor in recent years. People have come to see it as reckless. But that's nonsense. Most companies are the opposite of reckless - they are mired in indecision and angst. They need a good jolt, and they need to rebalance their behavior towards the "breaking things" end of the spectrum.

Does this resonate? Subscribe to my newsletter or reach out - we should talk. Links in the comments

What the heck is a "Chief Revenue Officer"?

I really struggle with teams and titles that involve outcomes vs. functions - especially in young/small companies.

For example. "Go to market", "Revenue" and "Innovation" teams

These are problematic for at least 3 reasons...

1. These kinds of outcomes should be everyone's responsibility everywhere across the company.

2. What they do is vague and can encompass all manner of "sins".

3. It's hard for the product team to engage with a big block/center of gravity known as "Revenue" instead of having direct levers to pull (this is particularly important in a product-led org where product managers need to have access to the levers of the company to make their product successful).

Instead, I prefer "Marketing" and "Sales" and "Product" teams. These are specific people with a specific function/culture.

These functions/capabilities come together to achieve go-to-market, revenue and innovation outcomes for the business.

Are you playing to win?

So many founders are just playing to survive.

So many investors are only willing to fund companies to subsistence levels.

My mother used to always say “Shoot for the stars and you will at least hit the tree tops”

Playing to survive means your vision is limited, your ability to raise capital is undermined, your likelihood to hire great people (who want to work on hard/big problems) is reduced and your probabilities for meaningful success are diminished.

#startups #scaleups #ambition #playtowin

Theory of change - incrementalism vs. ideals

Are you a bold instigator of change?

Broadly speaking, there are two theories of change.

Incremental and Ideal.

Incremental change suggests that you want to make small changes and corrections to find the right answer over time. It's typically associated with not wanting to "rock the boat" too much.

This is great when something is roughly working well, and you want to improve it carefully, consistently (but minimally) over time.

Ideal change suggests that you want to figure out a new medium-term ideal structure and work backward to create an efficient and pragmatic roadmap from here to there.

This is great when things are new, novel, or just not working as they are. It accelerates everything to a new normal.

Most people are too afraid to adopt the latter "ideal" approach when it's necessary. They typically prefer to deal with or instigate incremental change.

However, when important and fundamental things need changing, this is an ineffective, nightmarish process.

It leaves everyone stumbling around in the dark, slows the pace of essential change, minimizes the chances that each incremental adjustment will ladder up to the appropriate outcome, and is ultimately even more painful than just ripping off the bandaid.

One of the reasons for this is that - when it comes to incremental change - not only is the intended structure changing regularly, but so is the role that each part plays within that structure. Nothing is stable.

For example, if you're trying to re-org your company to a fundamentally new model, if you do it slowly, the org structure is changing, AND the roles and expectations of each of the people within that structure are changing. It's like quicksand. Everything is moving!

Instead, if you completely change the structure in one move, the only thing that keeps moving (improving) is people's understanding of their new role, their competency in that role, and the quality of overall execution within the new structure. Only one aspect of the org continues to evolve.

Be bold. Make important changes quickly and encourage everyone to catch up quickly.