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. 

The map is not the terrain

Regular Reminder: Data is not the real world.

Staring at your Data to make decisions is like staring at the GPS navigation system to drive your car.

If your entire world was that little GPS navigation screen, you'd think the world was a 2D cartoon with no cars or children on the road.

Similariy, Data can tell you what users are doing right now - but this is just a fraction of the bigger picture. What users are currently doing is a function of their current understanding and your current product UX.

Lift your gaze, look out the windscreen! There is a real-world informed by intuition, best practices, intention, common sense, and more.

Be data-informed. Not data-driven.

When is it time to retreat and scale back?

I’ve noticed many founders retreat when they should advance and advance when they should retreat.

Big off-strategy B2B deal that will derail the company? They advance headfirst!

Running out of money? They retreat - becoming more conservative and cutting important people - instead of advancing with a more aggressive focus on their key metrics and launching into an effective process of raising capital against a big vision.

#founders #startups #startupsnippets #scaleups #fundraising #focus