What's it mean to "Build the thing that builds the thing"?

If you’re part of the leadership team of a scaleup, it's essential that you focus on "Building the thing that builds the thing."

But what does that mean exactly?

It means you need to fall in love with designing your company for success the same way you might be in love with crafting a product or a partnership.

Here are some example tools that help you set the right context for your company - and what they're used for...

Business Context

Business Strategy

Ensures all stakeholders understand what the company is trying to do. Mitigates questions about what’s important.

Product Strategy

Ensures all stakeholders understand the product vision. Mitigates questions about what you're trying to build.

Product vision (design)

Ensures all stakeholders understand what the company is trying to build - mitigates debates about what’s important and helps everyone fast-forward to the future.

Operational Context

New Org Chart

Ensures all stakeholders understand what team they’re on and what they’re responsible for. Also helps the leadership team understand execution capacity and areas that require more investment.

Ways of working guide

Ensures all stakeholders understand their specific roles and how they should interact with leadership. Ensures leaders understand how to serve their people.

Definition of product

Ensures everyone in the company understands the true cost, complexity, and level of quality required for something to be a “product”.

Product principles

Set the product quality bar and create consistency across Squads and PMs.

Engineering principles

Set the engineering quality bar and create consistency across squads and EMs/Engineers.

Performance rubrics for key roles

Ensures that all people know what’s expected of their role and from each of their peers. Should reference many of the concepts in the other tools listed here. Must be used during performance reviews.

Planning Process

Ensures that all stakeholders know how planning works and their responsibilities in terms of participating in planning and maintaining alignment with the plan.

Definition of partner & customer types

Clarifies the specific relationships the company is trying to build and specifies exactly what support and product processes are needed to scale these relationships. Ensures minimal ad-hoc or one-off deals that can't scale.

Sales enablement for each partner & customer type

Helps to mitigate custom work by ensuring that each customer and product type is being “sold” the same thing (lead by product roadmap)

Employee onboarding process

Educates all new recruits about all of the above - ensuring consistent knowledge and culture propagation.

Is your "product" too complicated for Product Led Growth and Self-Serve?

If your “product” is “too complicated for self-serve” - then chances are, you don’t have a product. You have technology + services.

Consider…

• A narrower target market and problem

• A more opinionated solution

• A better user experience

If your goal is Silicon Valley-style hockey stick growth, you need to think again, think a little harder, and think about getting an experienced senior product leader to help.

Principles for cross-functional squads

I see a lot of confusion about how to create healthy and effective cross-functional squads inside scaleups and large companies.

Here are some key principles to keep in mind...

Missions, not projects

• Example missions include: User onboarding, billing & accounts, discovery, sharing & collaboration

• Avoid “Innovation” Squads - everyone should be innovating all the time

• Avoid Catch-all squads - every squad should have a clear mission that is broad enough to encompass many product changes over months and years while being specific enough to understand what is “in scope” and “out of scope” for the squad.

• Avoid Agencies - Squads should be building principles, tools, frameworks, services, and products for customers (internal and external) to use. They should NOT be regularly building one-off things for other squads like some kind of development agency.

• Be sure to include Platform Squads - These are Squads that serve internal customers with generalized services/capabilities.

Cross-functional & diverse

• Cross-functional squads are not just filled with PMs and Engineers - they should also include Product design, Product Marketing, Data Science, and even special roles unique to your business (E.g. ProdOps)

Full stack ownership and operations

• Squads triangulate, design, build, operate, measure, and iterate on their products. They are not just “delivery teams” that get instructions from others or hand things off to someone else once they’re built.

Autonomous but aligned

• Squads should be empowered to come up with their own plan and execute without relying on other squads

• They are aligned through planning cycles

• They are aligned through Group and CXO leadership reviews & escalation

• They are aligned through healthy (non-blocking) collaboration with other squads (see below)

Custodians, not Owners

• Squads shepherd given surfaces/services/outcomes - but do not block changes

• High bandwidth communication between EMs, PMs, and Engineers across squads as needed is essential. A graceful degradation strategy is useful. Specifically…

  • Rely on 3rd party squad’s existing tools where possible/desirable

  • If the existing tool is insufficient, suggest a change to the 3rd party squad

  • If the change is not on the 3rd party squad’s near-term roadmap, the 1st party squad can make a change to the tool (3rd party squad reviews diffs)

  • If the change does not fit within the 3rd party squad’s existing tools, 1st party squad should build their own

Supported by service leadership and escalation.

• Well-meaning peers in different squads will have a difference in goals and perspective. Reasonable disputes will arise.

• Everyone should be encouraged to escalate to leaders who have a broader perspective to make “executive decisions” and decide on trade-offs

Function-based communities/tribes/guilds create consistency across squads

• Individuals in a function report to someone in the same or similar functions (E.g. Engineers report to engineering leaders, not to PMs - and vice versa)

• Each function should engage in cross-squad culture building (shared principles, regular meetings, all-hands, social events, etc.)

Funded by the business

• New business initiatives/missions mean the funding and creation of new squads

• Squads become more granular with time, budget, and complexity of the business and the product

• Squads can be assigned more headcount and they can help hire for themselves

Accountable for outcomes

• Weekly or bi-weekly Business reviews with group/CXO leadership

• OKR reviews at the end of each cycle

Sales-led growth is like salt water

On Sales-led culture and growth:

“The problem is that most startups don’t realize that it’s like drinking salt water - it kinda quenches your thirst in the short term, but actually, it’s only going to make you very sick." - Ashley Angell

Maybe you should NOT be using OKRs

Using OKRs for a company organized as a monolith is like using a truck to pick up family groceries. It MIGHT get you there, but it will be slow, noisy, and unnecessarily painful.

What's a monolith?

Separate functional teams not organized as squads. One big engineering team rather than smaller mission-based teams with their own PMs, Designers, Data science etc.)

Re-think your culture and your org chart before putting lipstick on a pig.

The secret to product onboarding

What is the secret to product?

To put it quite simply (and reductively)...

1. Build something awesome that solves a real problem

2. Put it in front of the right people and get them to the value as quickly as possible.

The secret to product onboarding

With this in mind, be careful about one-time "onboarding" experiences that attempt to do too much work compensating for weaknesses in the core product.

Instead, consider how you can make the core product more easy-to-use, self-explanatory, delightful, and adaptable. And then get users in there as fast as possible!

The case for data

Those who follow me closely know that I am a big advocate for intuition and step-function change in product development - particularly at the start when you're building early momentum and Product Market Fit.

But this is a regular reminder to pay attention to the data.

If you have good momentum and some level of throughput through your product, you don't have to really guess about what to work on next.

Ask yourself, "What is the number 1 reason why more people are not more successful more often with my product?"

Number 1. Not 2 or 3 or 4.

Typically the best way to answer that question is by great product telemetry and funnel analysis.

Map out the ideal pathway(s) through your product, find the biggest drop-offs, develop some hypotheses about reducing the drop-off, and start testing!

If you don't take the time to do this, you'll forever be shipping "great" new features but never polishing the surface area you already have. By definition, this is suboptimal, wasteful, and a misuse of time and resources.

Everything, everywhere all at once

Reminder for non-product founders, ceos, sales people and investors:

R&D can’t do everything all at once.

You must give your product and engineering team time to execute in iterations.

If you insist on having everything all at once you are literally falling agile, iterative product development 101 and, in the process, thrashing everything and everyone.

Do you have the right number of people to get the job done?

When building your scaleup, it's easy to underestimate the number and diversity of people you need in org.

Each major division and product area needs its own squad with clear missions and a cross-functional mix of people to get the job done.

In my work, I see many scaleups experiencing a great deal of pain and dysfunction due to the leadership team underestimating the cost and complexity of all the "businesses" and "initiatives" they create.

Many of these efforts are, at best, unfunded mandates or, at worst, the result of a distinct lack of strategy and making hard choices.

Are employees like children?

When applying for a school for my 18 month old son, they asked "What expectations do you have for him once he graduates?" we wrote...

Our hope for Noah, once he graduates are the same as our hopes for him every day of his life.

That we can give him…

1. Enough freedom to imagine great things for himself and others

2. Enough discipline to have grit, determination, respect, and honor

3. Enough context to make informed decisions

4. Enough reasoning to perform good actions

5. Enough tools to positively affect the world based on his vision

6. Enough balance and perspective to know how to be in the moment and find contentment

Beyond that - we have no expectations to place on his shoulders other than those he would have for himself.

—

It occurrs to me that this is a good way to manage people in your company, too

Data can't tell you that you suck

One of the many things data-driven decision-making doesn't tell you is when people drop off your product because they just don't trust you.

Your logos, your colors, your voice, your layouts, and/or your general vibe may just be turning them off.

Maybe it's unprofessional. Maybe it's too corporate. Maybe it clearly shows a lack of attention to detail or quality execution. Maybe, just maybe, it's obvious you SUCK.

So you can spend a lot of time trying to optimize this part of the funnel and that part of the funnel - but what you really need is to take a step back and ask yourself broader questions.

Questions like...

1. Is this whole thing good enough?

2. Is this the right metaphor?

3. What kind of overall story am I tellin - is it possible I'm repeating myself or not setting enough context?

4. What end-to-end adjustments need to be made to make this experience more consistent and clear?

6 factors for raising a big round

Successfully raising a significant funding round requires the perfect alignment of various critical factors. Some of these factors are frequently overlooked:

1. Pedigree:

Background matters. Have you been affiliated with the right kind of orgs like Google, Uber, Stanford, or YC? Were you part of a startup with a successful exit? These kinds of places are known for creating and teaching the skills required to be a great product and startup builder.

Also, what makes you uniquely qualified to solve this particular problem? Sometimes referred to as Founder-problem fit.

Mitigation Strategy: Bolstering your team with a stellar advisory board can help compensate for a less notable pedigree.

2. Perceived Competence:

How strong is your personal and company brand? Do your presentation skills stand out? Are you well-versed in your key metrics? Can you impart unique domain insights or ways of thinking to investors that captivate their attention?

Mitigation Strategy: Intensive coaching and lots of practice can elevate your perceived competence.

3. Incredible Traction:

Is your product growing fast? Are you driving meaningful revenue? Do you have a unique asset that sets you distinctly apart from the competition?

4. Big Vision:

Do you have a compelling vision that makes an investor sit up and take notice? How does your initial traction turn into incredible network effects and help you break into multi-billion dollar adjacencies?

5. On-trend:

Being in sync with current trends is often key. While Generative AI is clearly the topic of the day, trends evolve and shift over time. How can you realistically and clearly draw natural connection to what you're doing?

6. Luck:

Everything in life takes a little luck. But luck is not a mystery. Luck takes "Preparation + Opportunity + Execution".

Have you done what it takes to prepare (see above), are you putting yourself in the right places where big deals happen (Silicon Valley, New York, etc), and are you executing a methodical and effective strategy for raising a serious round?

#productstrategy #fundraising #venturecapital #investing #startupsnippets #consultingconvos

R&D dysfunction typically comes down to people

Many of the dysfunctions I see in companies failing to build a high-performance R&D team can be boiled down to some combination of the following...

1. An engineering leader that is TOO opinionated and/or too concerned with technology

2. A product leader that is NOT opinionated enough and/or not sufficiently articulate about what they're trying to achieve and why

3. A senior leadership team that isn't listening to their engineering or product leaders or is failing to either a) hire better people or b) get them help in the form of coaches/advisors.

You need a CPO at a scaleup and bigco

It's essential to have a cross-functional group of experienced people with clear opinions in a decision-making process.

However, a group of well-meaning peers can't solve the problem alone.

It is also essential that there is a final decision maker who is empowered to...

1. Set vision

2. Create & maintain a consistent set of principles & decision-making patterns

3. Make executive decisions

4. Hold the team accountable

This is true for almost any process - but it's particularly true for Product Strategy and Product Management. This is typically a CPO who is empowered to lead the function at the most senior level.

Without this function in a scaleup and large company, decisions will be slow and less effective (often dramatically so).

#startups #scaleups #productstrategy #productmanagement #startupsnippets

Ideal product process

Canva recently released a new product process for their product org.

It is…

1. Vision (communicated by rough product designs)

2. Goals

3. Milestones (including design and user testing)

4. Build

5. Refine (sense check with internal team/founders… does it meet the quality bar, does it feel right)

6. Launch

I think it’s good but not ideal.

Here’s the process I like to use to build products that create step function change.

Strategy

1. Vision in roughly right, ambitious idealized design

2. Sense check with peers and leadership

3. Break into thin slices/milestones

Iterative/agile build (for each milestone)

1. Detailed design/requirements

2. Build/polish

3. Launch

4. Learn

5. Repeat

Without strategy, you get lost in incremental change. Without iterative/thin slices you get lost in development hell, disconnected from testing and market feedback for too long.

Marketing Automation malpractice

An absence of marketing automation is malpractice for any Product management/R&D process.

Every product release should include a Marketing Automation plan. This would include either the creation of new events or updates to existing events.

This also implies, of course, that Marketing Automation is not a MARKETING problem (despite the name). It's a product problem. It is a core part of the UX.

It can't be outsourced to the Marketing team or, worse, an agency.

Stop talking to your engineers!

Reminder number #42342 about maintaining a product-led culture…

At a scale-up or large company, sales, marketing, bizdev, CEO, etc should not be asking Engineering or Design to scope or build anything directly.

Scoping includes asking the question, "How hard would it be to...".

This is not a bureaucracy or control thing - it's an avoidance of chaos thing.

Design and Engineering do not have enough context to answer these questions or do this kind of ad-hoc work.

Because the question is not how hard it is to design or build something.

The question is IF we should build something, HOW we should build something (including handling edge cases, error cases, downstream implications etc), IN WHAT ORDER should we build something, and WHO will maintain it over time.

It's the job of Product Management to figure this out before it gets to Design and Engineering.

So sales, marketing, CEO-types - please talk to your friendly neighborhood PM.

Design & Engineering, please push back on these asks and loop in your PM to respond.

The Developer Platform Playbook: Canva Extend Case Study

I finally got a chance to watch the Canva extend developer platform event.

Link at the bottom of this post

Developer Platforms help you create defensibly for your business and elevate your product from a point solution to a critical part of the fabric of the Internet. It’s arguably the key reason companies and products like Facebook and the iPhone became as powerful as they are.

Based on their launch event, it is clear that Canva is running a near-perfect playbook for launching a new developer platform and ecosystem.

This includes...

• Deep buy-in from the business

• A deep understanding that “if you want to go far, go together.”

• Named and branded Developer program

• A HUGE focus on distribution and monetization for developers

• Meaningful innovation fund to supercharge the ecosystem + flywheel

• Standardized rails - no custom integrations

• Two clear modalities: a) In-app discovery, provisioning, and extensibility via “Apps” b) External connections via “Connect APIs”

• Easy to install and use SDKs with UI components and Sample Apps

• Strong opinions on design principles

• Awesome launch partners that clearly demonstrate key use cases

• A big-bang launch moment to incentivize and reward launch partners and kick-start the ecosystem + flywheel

• Developer advocates live on stage, showing code

• A long-term commitment (years)

This is the exact playbook I was running at Uber.

It's also the playbook I've helped companies execute as part of my advisory work.

In fact, the quote they cited, "If you want to go fast, go alone. If you want to go far, go together," was written on the wall where the Uber Developer Platform team sat.

This playbook is filled with counter-intuitive decisions and is often met with religious arguments (almost allergic organ rejection) by most people inside most companies. It takes a particular experience, mindset, and culture to truly understand the value of ecosystems, flywheels, and long-term thinking.

Massive Kudos to the team. I suspect Anwar Haneef had a lot to do with what happened on stage. I'm curious about who else was the driving force behind such pitch-perfect execution.

Watch Now

Have you found religion?

I spend a lot of my time explaining to traditional business thinkers, investors, and board members the benefits of a product-led strategy that is not corrupted by the pursuit of the wrong kind of short-term revenue and sales motions.

The reactions I get can generally be bucketed into three broad categories.

1. Skepticism and allergic reaction
   

2. Convinced and excited in the moment, but then they immediately revert to old habits when they have to make hard decisions.
   

3. Complete revelation and religious conversion.

It's most often the second.

It seems that some of the core tenants of the faith are...

1. Abundance thinking - to believe that the resources and techniques exist to succeed and scale (especially capital)
   

2. Conviction about the correctness, size and scale of the opportunity they've chosen to pursue - to avoid getting distracted by shiny objects along the way
   

3. Confidence in themselves and/or the team - to avoid paralysis and being crushed by the demands of great execution
   

4. Competence - to execute well and start seeing results

The road to hell is paved with good intentions

I am so passionate about helping earnest founders with a big vision achieve their goals.

Sometimes I jump on a first call with a founder who has a genuine heartfelt need to change the world for the better. For them, it's not about money or fame or any of the other trappings of traditional success.

I love these kind of founders.

But often, these founders are the ones who make the MOST mistakes in their early startup journey.

1. B2B when it should be B2C - Check

2. Franchise model - Check

3. Outsourcing the app to someone else - Check

4. Chasing validation from media, academia, government and/or incumbents - Check

5. Vague and ill-defined user problem - Check

6. Building a professional services business - Check

7. Starting in a small market - Check

On and on...

When I encounter these founders, I try very, very hard to gently but clearly and firmly redirect their energy back to the most effective path to success.

It's so important to me that all of this passion, enthusiasm, and potential isn't wasted by accidentally hitting these well-known landmines that are easily avoided.

This is why I do what I do...

If you're working on a social impact project or startup, please work with colleagues and advisors with deep experience in commercial success. While their motivations might be different, their insights into building things that engage users and scale fast are many of the same skills you need to make a social impact on the world.