Product & Startup Builder

The 7 deadly sins of Scaleups and BigCos

Added on by Chris Saad.

As companies get bigger they often get bloated, slow, and lose the ability to deliver new value, quickly.

During times of market volatility, this kind of inefficiency can not continue. Speed, agility, and efficiency need to be restored to exit a downturn with accelerated success and growth.

But what are the key mistakes these companies make that lead to a breakdown of meaningful value creation and innovation and speed?

Here are 7 common deadly sins...

  1. Poor context setting by the leadership team
    Before any group of people can make good, well-aligned decisions, they first need to be on the same page. The larger the group gets, the more explicit, and well-articulated the shared context must be.

    There are many forms of shared context. These include cultural values, definitions of what "great" looks like (for people, products, and processes), a vision for where the company is going, and more.

    Many companies fail to create these (or fail to create good versions of them) and share them with the whole company.
     

  2. Poor operationalization of shared context
    In many cases, shared context documents are developed, but they are not integrated into the day-to-day operational cadence of the business. Onboarding, hiring rubrics, performance reviews, planning cycles, day-to-day meetings, and everyday decisions fail to use the framing and vocabulary of the cultural values, definitions of great, product principles, etc
     

  3. Poor planning 
    Plans from leadership tend to be either a) too high-level or b) too tactical.

    Plans that are too high-level leave too much room for ambiguity and don't help the team make tough tradeoffs. Things move too slowly and/or do not align to create meaningful short-term value.

    Plans that are too tactical stifle innovation, decision making, and parallelism at the edges. Product managers and other leaders start acting as messengers instead of taking full ownership of their areas of responsibility. Good decision-making does not scale.
     

  4. Poor org structure
    Broadly speaking, there tends to be two bad ways that teams are organized.

    a) Teams are split by function rather than by purpose/problem/mission. Product, design, engineering, and other key functions sit in silos that don't interact well together. Tribes form and collaboration stalls.

    b) Teams are grouped into cross-functional squads, but the missions of squads are poorly designed such that there are too many cross dependencies between them. Clear lines of full-stack ownership are never fully established.
     

  5. Poor role design and ways of working
    Rather than build a better team, companies tend to hire more people in more specialized functions to compensate for the weaknesses of their existing team.

    This ultimately diffuses accountability and adds communication overhead to everything. It slows everything down. It makes it hard to hold people accountable.

    As a clear example, a product squad should basically only have 6 types of people. Product Manager, Product Designer, Engineering Manager, Product Marketing, Engineers, Data Scientist. Sometimes there's a need for 1 or 2 other specialist roles depending on the org/business.

    No Business Analysts, Scrum Masters, Product Owners, Architects, QA, Customer Experience, etc.
     

  6. Poor risk-taking
    Classic innovator's dilemma quickly sets in. Decisions start to become incremental and new ideas tend to be too hard to digest or feel too risky to pursue. In some terrible cases, an "innovation" team is created to try to compensate. Fail. Innovation is everyone's job.
     

  7. Piecemeal attempts to rectify
    Rather than leadership taking bold steps to address all of the above (and more), they often avoid making hard decisions or rocking the boat too much. Changes to the business and the org tend to be too incremental. Often times it feels like it's no one's job to really fix the problem and building consensus for hard changes can be almost impossible.
     

What can be done?

That's a post for another day!

A month in the life of a product manager at a scaleup

Added on by Chris Saad.

Once a month: A product leadership allhands

Everyone in Product Management (maybe also PMM, Design) in a big group meeting with the Head of Product (Optional CEO/CTO) to discuss company-wide, big-picture issues, cultural changes, and maybe some show-and-tell of big releases coming up, etc.

Once every 2 weeks: Optional Product Lunch & Learns

Optional opportunity for a product, design, PMM leader to share a best practice, a new idea, an industry trend, new cultural values, etc with whoever wants to attend. Informal, lunch-time slot that anyone can fill if they have something compelling to say to the group.

Every week: Company-wide Townhall/All-hands

Opportunity for CEO, CMO, CRO, and CPO to share company-wide updates. Perf cycle updates, planning cycle updates, and offer Q&A.

Every week: Group Leadership meeting

Every PM (and maybe Design/Eng leads) in a group, meeting with the GPM, GDL, GEM to discuss business updates, group updates, perf cycles, planning cycles, where everyone’s at, any blockers, and what everyone’s up to in the coming week.

Every week or 2 weeks: 1:1 with their immediate manager - typically the GPM

Chance to discuss any blockers, escalations etc. Also an opportunity to discuss career goals, performance etc. Tends to be less about the work and more about the individual. There might occasionally be "skip-level" meetings with their managers, manager.

Every week: Squad level meeting

PMs, EMs, Design leads meeting with the rest of their squad to update them on anything coming out of the Group meetings, the Town-hall, new missions, planning cycles, perf cycles etc.

Every week: Per PM/Per major initiative Cross-functional product alignment meeting

The PM leads a meeting of all the key stakeholders involved in getting their roadmap/releases out the door successfully. Support, Sales, Marketing, Design, Bizdev etc. “Here’s where we’re at for this release, here’s what I need you to know, here’s what I need you to do for this upcoming release, where are you all at?”

Throughout the week - Ad-hoc: Stakeholder workshops

PM meeting with whomever they need to meet with to get answers to their questions, flesh out their PRD, and drive alignment about an upcoming release. This can include…

  • Cross-squad coordination meetings to discuss with other PMs, Designers, EMs, etc any requirements/changes that might be needed from the parts of the product they shepherd

  • Deep-dive workshop meetings with sales, support, ops, etc to dig into key details for the next release (likely uncovered during the cross-functional syncs)

  • Meetings with the lead engineers for a given release to discuss scoping, technical details and ultimately handing off the PRD for technical planning

  • Meetings with designers to design screens and brainstorm on UX

Recession warning! Have the "End times" arrived?

Added on by Chris Saad.

Every 5-7 years or so, Silicon Valley and related tech hubs love to declare, "The End Times Have Arrived."

In the last couple of months, similar rumblings have been bubbling to the surface. With talk of rampant inflation, crashing stock market and crypto values, and increasingly nervous investors, startups are wondering what will happen next - and how to organize themselves to survive.

Here are some things to consider...

1. Recessions can be bad for traditional companies but can often be good for tech companies that represent greater efficiencies.

2. Some of the most important tech companies in recent memory were born during recessions - in particular, AirBnB and Uber come to mind. These companies offered customers a cheaper way to navigate the world while offering entrepreneurs another way to make some money on the side.

3. This effect can be seen in pretty much all sectors of the tech world, including medicine, commerce, logistics, healthcare etc. This is because, in lean times, companies can no longer afford to tolerate operating waste. Tech is usually the first, best answer to this challenge. In this scenario, tech products often move from being "nice to have" to representing an urgent solution to a pressing problem.

4. Making smarter, more effective decisions is key to surviving lean times and coming out the other side stronger and better than ever. This should be your internal mantra AND your pitch to customers.

5. You may need to shed staff and trim valuations in order to deal with tightening investor sentiment. However, this should NOT mean slashing your best or most essential people who help you make smarter, more efficient decisions.

6. Take this opportunity to invest in polish, scalability, efficiency of decision making, and high-quality execution to come out the other side with better products and more momentum than your competition.

Finally, I'd like to say that, despite doom and gloom prognostications from investors, these situations tend to be massively overblown. They tend to blow over in 6-12 months once everyone remembers that tech is well placed to benefit from downturns and that the sky, is in fact, not falling.

Stay focused, execute well, and deliver value, and you'll do fine.

Fundraising - like any deal - is like playing poker

Added on by Chris Saad.

Fundraising - like any deal - is like playing poker

There's no perfect answer. It's a game of negotiation and understanding the variables.

There's what's in your hand, what's in the river, and what's in the deck

Your product and metrics are what's in your hand. The reactions you're getting from investors are like the river (the cards in the middle of the table), the macro-economic conditions are like the deck in the dealer's hand.

Play each round. Pay close attention. Make the best deal you can.

How do you make sure the candidate you're interviewing is going to be a high performer?

Added on by Chris Saad.

How do you make sure the candidate you're interviewing is going to be a high performer?

Listen for ownership

Do they blame others for past failures? When you ask them how they get their job done, do they mention a lot of dependencies on other departments? Or do they express a sense of ownership and a 'pull-out-all-the-stops' perspective on their role?

Listen for speed/hustle

Ask them how long it would take to do something. Are they talking about days and weeks? Or are they talking about months? Is their timing aggressive while also taking into account practical realities?

Examine their portfolio of work

If it's a product manager, ask them to produce a PRD and brainstorm on it with you. If it's a designer, ask them to walk you through their portfolio. If it's a marketer, ask them to walk you through a number of their previous campaigns. Is their work fantastic?

Be wary of people who have exclusively worked at large companies or agencies

Unless they express extreme discomfort with the bureaucracy of big legacy companies or the unscalable nature of agency work - these people tend to either work too slowly or be too comfortable with unscalable solutions to business problems.

Any transition from Startup to Scaleup must begin with a pitch deck.

Added on by Chris Saad.

Any transition from Startup to Scaleup must begin with a pitch deck.

Pitch your team - and educate new hires - as if they are your investors. Bring them along on the journey about the problem, solution, prioritization, cultural values, etc.

In this way, any required org changes move from being perceived as "change is scary" to perceived as principled, logical, obvious, and exciting!

3 trio of trios for Product Managers

Added on by Chris Saad.

There are 3 beautiful trios that a Product Manager participates in

1. Product Manager, Product Marketer, Data Scientist

2. Product Manager, Product Designer, Engineering Manager/Engineers

3. Product Manager, Support, Sales

When these 3 trios are firing on all cylinders - the magic starts happening.

Does the engineering team in your scale-up suck?

Added on by Chris Saad.

Are they too interested in tinkering with technical challenges? Do they over-estimate and under-deliver? Are they making technical choices that don't scale or aren't fault-tolerant?

The first thing to do is take maximum accountability. You need to improve the context and constraints inside which they work to improve their priorities and decisions.

Specifically...

  1. Ensure they are organized into mission-driven, long-lived, cross-functional squads (Product managers, Engineering Managers and Engineers working together) rather than an amorphous "engineering team" or "core platform team".

  2. Ensure each squad is led by a strong engineering manager with the right balance of technical credibility and business acumen

  3. Ensure each squad has a strong Product manager who is setting priorities and creating lean, thin slices of minimum viable releases.

  4. Ensure that Squads set ambitious outcome-driven OKRs. Key results with user adoption metrics or funnel conversion metrics are best. Launch dates are much less ideal. Unmeasurable Key Results are a fail.

  5. Establish effective engineering-specific cultural values. How they should interact with each other, product, and other functions.

  6. Establish high-quality technical principles that define how to approach problems. Testing, performance criteria, and more.

  7. Develop principled performance review rubrics that operationalize the cultural values and technical principles. Without these, your values and principles are just words on a wiki.

  8. Develop onboarding and professional development programs that educate on the values, principles, performance review process, etc

  9. Hold people accountable. FIRE low performers

  10. Hire better people - especially PMs that can push back on engineering (with better requirements, leaner scope, smaller iterations etc) and EMs that know how to encourage business-focused outcomes from engineers

My exotic car obsession has made me a better product manager.

Added on by Chris Saad.

I’ve learned at least as much about product and product management from my recent obsession with exotic cars that I have from working in digital products for 20+ years.

Particularly the way Porsche can create 15 flavors of the 911 and 718 - one for each use-case and point along the spectrum of price and road/track focus.

It’s the kind of precise product/market you see from only the very best tech companies.

Be careful not to dismiss principles "academic".

Added on by Chris Saad.

Be careful not to dismiss principles as "academic". They are essential foundations for consensus-building that drive alignment and improve behavior.

Avoid dismissing ideals because "we're not there yet". You will never get there until you agree on the ideals and make the decision to change your behavior/goals.

You're there when you decide to be there. If you never decide you will never get there.

Managing conflict in your business and in your team

Added on by Chris Saad.

As a founder, how you deal with conflict, misalignment and sub-optimal behavior from employees or vendors is more important than how you deal with things going well.

To be an effective operator you need to...

1. Take maximum accountability for other people's misunderstandings, underperformance, or confusion, and correct your own behavior before blaming others.

2. Have hard conversations and establish new boundaries before things reach a failure state.

3. Set clear goals and use carrots and sticks to encourage changes in behavior.

4. Provide fair and reasonable pathways for remediation.

5. Treat people respectfully and ensure they are compensated well even while you might need to move them out of the business. This might include agreeing on a new/different role (with different titles and terms) to better reflect their abilities or contribution.

6. Do most of these things a) in private b) on the phone or in-person rather than via email (document actions in an email afterward).

Management is not all it's cracked up to be

Added on by Chris Saad.

Juniors in a function should report to senior members of the same or similar function.

For example: Designers should report to Group Design Leads who report to Head of Design. Engineers should report to Eng Managers who report to Group Eng Managers and so on.

There are exceptions where functions are similar. E.g. it makes sense for designers to ultimately (toward the top of the org) Product. It makes sense for Data Scientists to ultimately report into Engineering.

Stated in the negative, Product shouldn't report to Engineering. Design shouldn't report to Marketing.

Why?

This is because it's essential that managers can be of service to their direct reports. They must be in a position to provide guidance about their craft, perform fair performance reviews, nurture their career during 1:1s, and help them resolve interpersonal issues that might be unique to their particular area of responsibility.

But what about when individuals are deeply embedded in a department (as they should be)? For example, what happens when designers are working closely with Marketing. They need to be able to heavily influence the work the designers are focused on, right?

This is solved by splitting "management" into two separate parts:

Part 1: Management of people, culture, and craft: This is performed by your "manager". They help you understand HOW to do your work. They are the "solid" line on the org chart.

Part 2: Management of workload and priorities: This is performed by your "colleagues". They help you understand WHAT work to prioritize. They are "dotted" line on the org chart.

By splitting it this way, you get the best of both worlds and unlock the potential in your team.

Are you failing to find product-market fit? Time for a Pivot?

Added on by Chris Saad.

Are you failing to find product-market fit?

A pivot might be in order.

However, be careful.

When thinking about and researching your pivot, you might be a little gun-shy. Having failed to hit it out of the park the first time, you might be tempted to try to achieve 100% conviction about your new direction.

This isn't going to happen.

Get to 80% and pull the trigger.

Endless indecision is worse than a sub-optional decision. Move fast, ship, learn, iterate. Risk is part of the game.

Also, when making a Pivot; don't half-ass it.

There's nothing worse than making some changes in your roadmap or marketing but not going all the way to align everything in your business with the new direction.

Don't hedge. Don't leave things out of your pivot. It's likely everything needs to be reviewed, adjusted, or completely changed.

In short:

Get to 80% conviction

Pivot 100%

There's a fine line between Elizabeth Holmes, Travis Kalanick, and Steve Jobs.

Added on by Chris Saad.

There's a fine line between Elizabeth Holmes, Travis Kalanick, and Steve Jobs.

They all bend the universe to their will. They all inspire people with vividly drawn and compelling visions of the future.

The difference between them, however, is the degree to which they know which rules/constraints to break (many), which to manage through (most), and which to respect (some).

When it comes to managing through constraints, they know how to dig in and pragmatically solve problems instead of constantly reverting back to big-picture nonsense. They don't avoid the details - they crush them.

Try to avoid "Stretch goals" or "Second" Priorities on your Roadmap.

Added on by Chris Saad.

Try to avoid "Stretch goals" or "Second" Priorities on your Roadmap.

Stuff is either important - in which case it's on the roadmap - or it's not. In which case it's not.

A roadmap is a linear, opinionated sequence of stuff you're going to deliver. Not a universe of possibilities. It should allow you to communicate hard decisions and tradeoffs about what gets done next and what might get pushed back if new priorities are added.

This makes it distinct from a backlog and other tools you might use to triangulate your future workload.

Moving from engineering to engineering leadership requires that you start using different tools.

Added on by Chris Saad.

Moving from engineering to engineering leadership requires that you start using different tools.

The priority becomes scaling yourself, aligning stakeholders, and inspiring action. As such...

  • You end up writing less code and start writing more values, principles, and patterns.

  • The elegance of your architecture becomes less important than the eloquence of your words.

  • The things you say become less important than the sound of your voice when you say them.

What are the Key Roles in a young startup and why is it important to get them right?

Added on by Chris Saad.

I often find people working with young startups who are not quite sure how to position themselves, their equity holding, their influence, and their accountability in the business.

It's essential to label people's roles and responsibilities correctly. It has many benefits including a) smoothing out day-to-day operations by making areas of responsibility and accountability clear b) accelerating fundraising by helping investors understand whom to talk to and whom they're investing and c) helping key employees feel valued and incentivized to give their blood, sweat, and tears to the business by ensuring they have the right title, responsibilities, and equity.

Here are some key roles that are often conflated and confused.

Operational (co)Founder: Someone who's played an instrumental role in the formation of the company (likely taking on significant risk at the beginning by working without pay) and (crucially) will continue to play a full-time operational role in the business moving forward. This person should have a meaningful equity position.

Non-operational co-founder: Someone who may have contributed to the initial formation of the business but has other commitments that limit their availability to participate in an operational capacity. They might play a role on the board or provide capital as an investor (see below for definitions) but are not involved day-to-day. This person should have a minor equity position for their initial founding contribution (+ any additional equity they earn through capital investment).

CEO: (Very) Ideally a (co)founder. Plays a full-time key operational role in the company. Makes key decisions. Leads essential operational workstreams such as fundraising, hiring, vision/goal setting, etc. Once capital is raised, is (very) ideally only involved in running the given startup and has no other operational roles in any other business. Must have meaningful equity.

Investor: Provides capital and some non-operational support (advice, intros, reputation, industry connections etc). Collectively all the investors can have meaningful equity in the business but must not have a larger position than the operational founders.

Board member: Either an external (wasn't involved in forming or investing in the company) key industry professional who can help steer the business or a key representative(s) from the investor group. Might also include a non-operational founder who has seniority, domain expertise, and perhaps provided initial capital.

1 person can perform multiple functions in the business and, as such, be attributed equity from multiple pools/reasons.

However, it is value destructive to the company for someone to have the title and/or the equity of another role but not properly and fully perform the duties of that role.

As such, it is against their best interest to do this since, whatever equity they hold, will be under-valued or ultimately be reduced to zero when investors and other operators choose to under-invest or walk away entirely.

#equity #fundraising #jobtitles #strartups

How is making Products similar to making Marvel movies?

Added on by Chris Saad.

There is still so much confusion about what Product Management is.

I'm a film nerd. So let's use a film production team as a metaphor for the Product Manager.

  • Executive Producer = CEO. They have an idea. They have money. They might even have a script.

  •  Set Decorator/Costume Designer = Brand and Product Designers. They design beautiful things.

  •  Set Builders/Camera Operators = Engineers. They build amazing things.

 However, if they were all sent to a movie set they'd fail to make a coherent movie.

 They need a director.

  •  Director = Product Manager. They have a vision for the story they want to tell. They have an emotional journey they want to take the audience on.

 They work with the set builders to build the right kind of physical spaces that support the action.

 They work with set decorators and costume designers to make sure there's a consistent color pallet and design language.

 They work with the editor to make sure the story makes sense and key moments are emphasized.

 They make sure all the amazing craftspeople are making the same movie. They help them stay aware and aligned around the key emotional beats of the story to ensure that the audience walks away with the intended catharsis - laughter, fear, excitement, delight, and more.

 That's what Product Managers do for users.

Founders can really help or hurt their scaleups

Added on by Chris Saad.

When you become a bigshot founder of a scaleup, your every word and behavior is closely observed and acted on.

This gives you the power to do a lot of good, and the power to do a lot of damage.

I've started working with some incredible scaleups that are each, in their own right, changing the world.

Part of my work, however, includes working with founders to adjust their engagement with the expanding team so that their superpowers are used in the best, most constructive way possible.

As a founder in this position, you must move from "getting shit done" to "building the thing that builds the thing". This means that your primary strategic levers to drive change are not cutting code or running products, but rather explicitly defining a great culture, communicating high-level business priorities, establishing effective ways of working, and funding teams to succeed.

The primary way you tactically interact with individuals day-to-day moves from telling them what to do, towards reviewing work and encouraging everyone to be more aligned, more ambitious, and more effective in their decision-making.

By doing this, you show your team that it's their job to come up with bold answers that move the needle, and you give them the space to do their very best work.

It's hard to make the switch, but make it you must, or you will ultimately thrash your team and deliver sub-optimal results.