The business alignment stack

It's hard to drive alignment and reduce thrash in any business. One of the tricks is to nail down each layer in the business stack - in order. How?

1. Zero in on a clearly and narrowly defined problem

You need to fall in love with a problem, not the solution. Unless you clearly figure out the problem you’re solving you won’t properly understand the pain you’re alleviating and the value you’re creating

2. Develop a business strategy

Who are your target customers? Who is feeling the deepest pain, inefficiency, and waste from the problem you're solving? Are you attacking this problem via B2B SaaS or via B2C tools? Is there a more direct and efficient path to market? Who are you disrupting? What is your business model?

3. Craft a product strategy

How does your high-level business strategy map to an actionable product roadmap? What does the ideal version of your product look like? What do you NOT do? How do you solve for single-player before requiring network effects?

4. Map out a tactical product roadmap

Work backward from your ideal product. What is the tactical, pragmatic MVP? How will you make it easy and delightful for users to understand your tool and derive value quickly? What is your plan to iterate from a simple MVP to your ideal product without getting distracted and derailed?

5. Develop product marketing resources

Where do your target customers hang out? What are the key ways you communicate your value? What materials do sales, marketing, and partners need to succeed and sell what you’re building?

6. Execute marketing motions

How do you broadly and directly distribute your message to the right people at the right time? How do you establish brand credibility, lead nurturing and convert users through your funnel?

7. Enable and activate the sales team

How will you get your products directly into the hands of your largest customers without a) compromising your product strategy and b) relying on distribution partners and gatekeepers? How will you enable your sales team to sell what you're product team is building vs. building what the sales team sold?

8. Nurture distribution partnerships

How will you scale by teaching distribution partners how to leverage everything you’ve built and learned with your own customers? How will you ensure they are supercharging your efforts rather than acting as gatekeepers and stumbling blocks in the market?

Should you be worried about the big players in your space?

PM I'm working with "They are big enough to steal what we show them and beat us to market"

My response: "They're big enough to be paralyzed by the innovator's dilemma - so if we are executing well they will be unable to pivot and execute fast enough to keep up with us."

The key part there was "if we are executing well"

It's more likely that you will kill yourself through poor execution than the big players in your space will come and copy+crush you.

How much should you pay for staff or vendors?

As a leader of a high-impact individual or team, be careful about paying too much attention to "hours worked" vs. "hours saved" and "impact made".

Imagine you have a problem with a highly specialized type of car engine. Something that multiple mechanics have spent hours trying to diagnose without success.

Now imagine you bump into a mechanic who has spent 20 years learning how to fix every possible problem with your particular engine.

They show up, flip a switch and your engine is fixed in 5 seconds.

Did they spend 5 seconds fixing your problem? Or did they spend 20 years and 5 seconds? Should they be paid for 5 seconds of work or for the value they created by fixing a previously unfixable problem?

Obviously, the answer is that their value far outweighs the amount of time they spent.

This is how a great leader values staff, teams, and vendors.

They factor in the saved time and the overall business impact of the contribution.

In fact, they are happy to pay a premium for speed and quality execution because they also understand the money saved from

a) All other operational costs that would have been incurred due to delay (e.g. imagine how many employee salaries, rent, etc are being spent when taking the slow path to an outcome)

b) Execution risk

c) Opportunity cost

d) Thrash

e) Other "soft" costs

APIs are both the easiest and hardest things in the world

The easiest thing in the engineering/tech world is to make an API Endpoint. The hardest thing in the engineering/tech world is to make an API Product

Inline Config UX

Configuration UX should, to the extent possible, be in-line with UX for day-to-day usage.

E.g. If I can edit the name of something, I should be able to click it and change it. I shouldn't have to go to some other form somewhere else unless absolutely necessary (e.g. if a change requires a complicated workflow)

My most important lesson

In all my years in startups, the most important lesson I’ve learned is this...

Those that build the right product and broadly market it most effectively, win.

The rest - those who philosophize, hesitate, pontificate, get bogged down chasing one off “deals” and “partnerships” etc. they all lose.

Good defaults

Good defaults are one of the most important features of your product

How to answer the question of platform and gatekeeper risk?

If an investor is asking why “Platform X can’t just do this” the answer is…

Direct to customer - We’re not waiting for them

Innovator's Dilemma - They won’t even try

Focus, focus, focus - If they try, they won’t follow through.

Network Effects - If they follow through, it will be too late.

Build vs. Partner - Eventually they will need to partner with us

Historical Precedent - This has all happened before and it will happen again.

It shouldn't be hard to pitch your product

If you find yourself trying to convince a prospective customer of something in your sales pitch, then you might have 1 or more of the following things going on...

1. Wrong product

2. Wrong prospect

3. Wrong pitch

In relation to the pitch: Try to find a way to frame what you do in the context of a tactical and urgent problem. Make points that are irrefutable.

Don't listen to your sales team

First a reminder: The goal of a product-lead, high-growth startup is not to fully serve the needs of an individual customer. It is to build a product that can scale quickly by serving the needs of a broader market. Products like this are focused, polished, easy to understand, easy to use, and require minimal support from customer service. Read more here.

----

I see a lot of inexperienced b2b product managers who actually perform the function of project managers or account managers.

They spend most of their time triaging high-priority contractual obligations from customers (as negotiated by the sales team) into a jam-packed roadmap.

The sales team are amazing collaborators who should be deeply involved in the product ideation & road-mapping process.

They should not, however, be in a position to dictate features or product direction based on the needs of one or two customers.

Why?

Because sales teams represent an inherent dichotomy for product managers.

On one hand, they have an intimate understanding of what customers are asking for. On the other hand, they are often ill-equipped to understand the full product and prioritization implications of those asks.

This means that they are a strong source of customer feedback and market insights. But they are also a common cause of roadmap thrash and strategic drift.

Creating a strong, healthy, and productive relationship with sales demands a disciplined and effective product management process.

This requires experienced product managers to...

1. Help the company get very, very focused on what problems it's solving and how. This might mean narrowing everything from the buyer persona, the target verticals, the geography, and even the specific use-cases.

2. Have a healthy level of disregard for the needs of a single customer, and, instead, focus on what the business and the broader market really needs. For example, the business model may call for a b2c product strategy while specific customers might push for more b2b SaaS style features like white-label. A specific customer might want the product to solve their adjacent business problems, but the product strategy might require that the roadmap remain focused on a specific category of features and problems.

3. Craft a clear and reasoned roadmap that allows their sales partners to understand the near-term, mid-term, and long-term evolution of the product. The roadmap should be described in user-experience and/or business value terms. Once a good roadmap is created, a lower-fidelity, near-term version might also be used as an alignment and communication tool with customers.

4. Heavily invest in sales enablement: Help develop the decks, docs, and narratives that the sales team uses in the field to sell the product that they're actually building.

5. Inspire the sales team with all the use-cases and business benefits that the current product and product roadmap can unlock for their customers. Encourage them to build a pipeline of customers for the product, vs a pipeline of product asks for their customers.

6. Carefully manage "can't we just..." and "isn't it easy to..." style conversations. Remain disciplined and help the company understand the true complexity of building and maintaining each new feature. Every addition to the product takes time and sustained investment.

Don’t let engineering deflect you from your product strategy.

I see a lot of inexperienced product people who have done a lot of work to figure out the next best thing to do with their product to meet the needs of the business and customers - only to be deflected by limitations presented by the engineering team.

The engineering team are amazing collaborators who should be deeply involved in the product Ideation & scoping process.

They should not, however, be in a position to deflect or distract you from your carefully prioritized set of features & requirements.

Why?

Because many engineers & engineering teams have an inherent dichotomy.  

On one hand, they are typically skeptical, conservative & reticent to make big, risky bets. Often with good reason. 

On the other hand, they are magical wizards. Once challenged to make something difficult, they will typically ultimately figure out a way to make it happen.

This requires product managers to...

1. Have a healthy level of disregard for the constraints inherent in the technical details and focus on what the business and customers really need.

2. Come up with a roadmap that allows their engineering partners to chip away at the problem towards their original intended goal within the technical constraints (vs heading off in a different direction)

3. Have faith that their engineering partners can make it happen given enough time and support.

4. Inspire their engineering partners to rise to the occasion.

Why non-profits often fail to achieve real change

As someone who's run both an egalitarian non-profit and been involved in a highly-effective corporate:

Egalitarian non-profits often struggle to achieve their goals because...

1) The profit motive is an enormously useful tool to focus efforts and determine if given actions are effective or ineffective. When you deliver a product or service that people pay for you know you've created real value. Money is value exchanged for value.

2) Egalitarianism doesn't work when you're trying to deliver disruptive change in the form of products and services. Hierarchy is required to make decisions, make tradeoffs, hold people accountable, and more.

Are you a product manager or an account manager?

Too many product managers in b2b are actually project managers and account managers.

They spend most of their time triaging high priority contractual obligation’s from customers into a jam packed roadmap rather than developing a strong strategy Based on broad market needs, trends, best practices and intuition.

#consultingconvos

Go faster

Life is like a treadmilll. If you’re taking “one step at a time” at a slow pace you’re basically going backwards.

Said more literally: The universe trends towards entropy (chaos). So if you want to impose any kind of order (I.e create something new) you must move at a speed that outpaces the natural rate of decay.

The road to product hell

The road to product hell is pathed with "It's already on the roadmap", "it's on strategy", "it's a quick win"

The key customer-facing roles for a Dev Platform

Running a developer platform? Make sure you have the right customer-facing teams…

1. Developer Relations (DevRel) team: stateless, performative, 1:many representatives that get the community fired up and help every-day developers however they can

2. Partner Engineering team: stateful, high-touch 1:few support of strategic partners.

3. Customer Success team: stateful, mid-to-high touch 1:few support for onboarding customers pre and post-sales.

Copywriting is a big part of design

Copywriting is a massively under-rated part of product design.

The right word choice on a button can change its effectiveness from being unintelligible to crystal clear without changing a pixel.

Scale is the goal

Scale is the most important goal for any startup. It's one of the key things that drive massive disruption.

But how do startups scale? How do large companies act and disrupt as startups do?

That's the number one thing that most founders and companies I encounter struggle with. They're often moving too slowly or building technology that is too hard to sell, support, and use. What follows is my attempt to explain the process of product development and scale as simply and clearly as I can:

1. Scale requires growth

2. Growth requires repeatability

3. Repeatability requires standardization

4. Standardization requires polish

5. Polish requires focus

6. Focus requires prioritization

7. Prioritization requires that you make hard choices

8. Making hard choices requires saying no

9. Saying no requires discipline

10. Discipline requires conviction

11. Conviction requires a combination of vision, faith & data

12. Vision and faith requires leadership

But what do each of those things really mean?

I've written a presentation that explains each step. Grab it below.

View PDF Version

You need to give a shit!

You can do all the business analysis in the world - but if you don't give a shit about solving a specific problem or injustice you see in the world, your business likely won't work. Or worse, it will work and you'll be stuck having to manage something you aren’t passionate about day-in and day-out.

How do you build products and businesses that can't be stopped?

The answer: Flywheels

Flywheels, in the context of product and business, are when “Thing A” encourages/drives “Thing B” that then, in turn, drives “Thing A”. Around and around, faster and faster.

A common and basic example of a Flywheel is the following phenomena on Facebook: Users on FB invite other users which, in turn, makes FB more useful, which then encourages more users to join Facebook.

Flywheels create acceleration and defensibility in your business. If they gather enough momentum, they make your business unstoppable. So, as you can imagine, they are a pattern that many product managers and startup founders try very hard to create.

Flywheels should...

1. Be built into your core product user experience

2. Be designed around an interaction model whereby the more users use your product, the better your product becomes to use

3. Feel like a natural part of the primary utility of your product

To do this your product will likely need to...

1. Work very well in 'single-player mode'. This is important to overcome cold-start bootstrap problems

2. Have a compelling 'multi-player mode' that feels like a natural and powerful part of the primary purpose of the product

3. Offer incredibly easy ways to invite friends or colleagues

4. Provide an incredibly easy and slippery onboarding funnel for invited users

A good counter-example of an effective Flywheel is offering users a discount code to share with friends or colleagues. This is not organic to the core utility of your product, nor does it make the experience better for either user. Another good counter-example is manual business development or sales activities. These are not deeply built into your product and are therefore too slow and cumbersome to scale.