Product & Startup Builder

Short-term wins vs. Long-term growth - A false dichotomy.

Added on by Chris Saad.

There's always this perceived tension between short-term wins vs. long-term growth.

I generally find it to be either...

a) A false dichotomy (because if you figure out the right long-term plan, you can take quick incremental steps in the given strategic direction to drive short-term outcomes while building towards sustainable and meaningful long-term innovation.

b) Even if there's a juicy (hard to pass up!) short-term win that isn't aligned to a long-term strategy - it's generally a lousy tradeoff that both costs more than you'd expect and returns much less than you'd hope. Thrash, distraction, and tech/business/ops debt combined with lackluster outcomes all conspire to just make it a shit deal

Take the time to capture all the ideas for real, meaningful long-term innovation, stack rank them, and THEN choose the top candidate that will move the needle.

Then develop a roadmap of thin slices in that strategic direction to drive short-term growth on the way to long-term change.

Have you wet your pants?

Added on by Chris Saad.

For an early-stage disruptive startup, using a big partnership to build something or go to market is a lot like wetting your pants. It might feel warm and fuzzy at first, but then you realize you've made a bad decision.

B2C wins

Added on by Chris Saad.

Pretty much all winning software is B2C in the sense that individual human beings have to love using it and succeed.

The most user centric product will always win in the end. Even if the business model is ostensibly b2b.

The b2b software that goes beyond the business user and helps the end-user the most, will destroy (b2b2c).

And in the fullness of time, b2c software companies will disrupt many of the incumbents and their crappy b2b Software.

Consumer App Pillars

Added on by Chris Saad.

When it comes to building a successful consumer app, there are 3 pivotal things you have to get right.

- A new or novel behavior that makes users feel something or achieve something.

- An elevated design that makes the experience feel delightful.

- An unfair distribution advantage and growth engine with continuous monitoring and improvement.

This does not guarantee success, but it makes it much more likely.

Keep grinding until you figure out all three!

Reusable documents

Added on by Chris Saad.

You don't need to work so hard to help your colleagues.

Often, when a colleague asks you to answer a question about your strategy, project, department, or other area of work, your first instinct can be to craft a bespoke answer to the question. This can often involve making a new document, diagram, or even a whole slide deck!

Stop.

You can avoid doing so much work.

Instead, consider how you might develop an evergreen canonical document, slide deck, or diagram that would answer the question (and probably many other questions) that you can use over and over each time someone asks the same or similar question.

The wonderful advantage of this approach is not just saving your time and effort. It also gives your colleagues who might keep circling around the same topics the confidence that there is one consistent plan that is always in effect and driving all decisions (and if there isn't - there SHOULD be).

By showing them the same diagram each time, their visual memory is triggered and they can think "Oh thaaaat's right - I've seen this before, and the answer is obvious and consistent each time I ask".

I always like to have these kinds of diagrams and documents laying around (to name just a few).

1 x product strategy deck (including principles, assumptions etc).

1 x product stack diagram

1 x roadmap

1 x problem/persona description/diagram

1 x org chart

And so on...

Stop doing so much work.

Stop making up your answers on the fly.

Stop re-formulating your information over and over.

Take advantage of reusable documents and your audience's visual memory to engender more confidence and deliver better, more consistent results.

Minimum Viable PROBLEM

Added on by Chris Saad.

You need something CRITICAL before you create your MVP.

MVP standards for Minimum Viable Product.

Most founders think that the FIRST thing they need to do is develop their MVP

This is WRONG.

What they ACTUALLY need FIRST is their Minimum Viable PROBLEM.

This is an embarrassingly narrow subset of the broader problem that you want to solve. A very specific persona, problem and use-case that is far, far more conservative and narrowly scoped than is typically suggested by your full vision.

Having a Minimum Viable PROBLEM allows you to build a TRULY Minimum (small) Viable (actually solves the problem) Product (Usable and delightful).

I am hereby coining the phase MVP(roblem).

The virtue of waitlists

Added on by Chris Saad.

Ship early and often.

Consumer app?

Try a waitlist. It can create scarcity, buzz and enthusiasm even while allowing you to throttle growth and measure app improvements by cohort.

There are a lot of good ways to make waitlists that really work for you.

Drop me a line if you're interested in learning more

Documentation helps to clarify thinking

Added on by Chris Saad.

Never underestimate the value of forcing people to document their thinking.

It uncovers subtle misalignment and confusion.

It also helps to force them to think about how they think, which tends to improve their thought process!

Deconflate to scale

Added on by Chris Saad.

It's amazing when restructuring a scaleup for true scale and efficiency how many new fertile areas and insights emerge when you deconflate and decouple each aspect of the business and its processes.

It really helps you uncover and dig into important details for standardization and scale.

Helpful people can be very unhelpful

Added on by Chris Saad.

If you have no real product and you start pitching to customers, your "market validation" can often just be a mirage. This is because people often try to appear kind, helpful, or smart - so they just say hollow things like, "Oh, that sounds like a great idea!"

This kind of feedback does not prove they will actually use your product when you put a real thing in front of them.

Similarly, if you have no real traction and you start pitching VCs, then they will start firing brain farts at you, which can be really distracting. They will say stuff like "oh, this would be better if it was in this other vertical".

Focus on growth before pitching VCs. Particularly if you're a first-time founder and/or you're getting this kind of feedback/objection.

Growth transforms your hypothesis into fact. It will minimize or eliminate debate with well-meaning but misguided investors.

Everything else is academic.

God is in the details

Added on by Chris Saad.

Some cultures and companies can be afraid to be "nit-picky" with each other.

I have recently noticed this in a group of PMs reviewing a product iteration on staging. Much of the feedback was prefaced with "this is just nitpicky but..."

Don't be afraid to dig into pixel-level details.

As a leader, be intentional about building a culture where teammates don't feel a need to apologize for this kind of rigor.

The details are the difference between good and great.

A trick for AI Customer Service Chat bots

Added on by Chris Saad.

A big watch-out for AI customer support chat bots:

Don't just deploy a chatbot. Build incredible documentation and a searchable knowledge base, then use THAT as the RAG for the bot.

You get to kill two birds with one stone + some people hate bots.

Chatbots are a layer of abstraction above knowledge bases and product info - not a replacement for them.

Generative AI changes EVERYTHING, right? Wrong.

Added on by Chris Saad.

Startups and products are about solving real problems from first principles.

Sometimes, a fundamental change occurs in regulation, culture, macroeconomic conditions, and/or technology, allowing you to re-think the problem and solution space from new principles.

Generative AI is such a fundamental change.

But the original intention/goal/pattern doesn't change. Solving real problems.

Decisive vs Thrashy

Added on by Chris Saad.

Don’t do this.

Founder running a company with huge potential - but it’s going sideways. He reaches out asking for help getting to the next level and unlocking growth.

We engage.

We have 1 meeting.

He cancels.

Months later he reaches out to engage again.

I decide to give it another chance despite my reservations.

We have 1 meeting.

Then he emails saying he wants to switch to working via written questions.

I explain this is a bad idea but I’m open to trying it as an experiment.

His submits written questions that are about me, not his business.

I answer the questions I’m willing to answer.

He cancels.

🤔

I’ve worked with only a few people who I would consider completely incompetent.

Very few people act like this.

But this is an (very) extreme version of a common trait amongst inexperienced operators: a lack of consistent execution and follow through .

NOTHING will work if you don’t do it consistently over time.

Making fast, thrashy decisions can feel decisive, but it’s likely to be wasteful and blunt any momentum you might have otherwise experienced.

Effective leaders walk the line between acting consistently and concienciously over time, and being agile enough to appropriately adjust to changing conditions.

Ineffective leaders get this balance wrong. They just spin their wheels and drive everyone around them crazy.

How do startups find me

Added on by Chris Saad.

I've had a number of people ask me recently how I find and select the companies I work with.

The answer is quite straightforward. But the last method might surprise you.

My primary sources of deal flow:

- Ambient reputation: People have heard of me (but they're not quite sure how) so they google for me and reach out from my site.

- Word of mouth: Founders I've worked with tell other founders to reach out to me.

- Social media: People stumble onto my social media posts, go down a rabbit hole, and then reach out because my world view and advice resonates with them.

- Newsletter: People have read a newsletter (sometimes because someone forwarded it to them) that alerts them to a problem or opportunity in their business. They then reach out from my site.

- Podcast: People are discovering and listening to my podcast regularly. It's growing fast (from algorithms or listener shoutouts). Some founders and operators like what they hear and reach out.

.

- VCs: Investors suggest founders contact me under 2 very different scenarios. a) They meet a lot of companies that are not yet ready for investment, so they send them to me to help them get ready, and b) They invest in companies and then learn about an opportunity or a weakness that I can help with - so they introduce me - this de-risks and maximizes their portfolio outcomes.

- Licence plate: You wouldn't believe the number of people who have stopped my wife, my dad, or me at the lights and asked about the plates on our cars (STRTUPS) - and then they want to connect.

My criteria for choosing to work with a company:

- 6+ months of operating capital.

- Potential to disrupt some fundamental aspect(s) of the world.

- A founder with ambitious goals.

- A coachable team, eager to evolve and improve quickly.

- A deep appreciation for opportunity cost and the value of moving fast.

- A “Chris-shaped hole” in the team where I can add a lot of value quickly.

You work for your direct reports

Added on by Chris Saad.

In the old world, your direct reports worked for YOU.

In the new world, YOU work for your direct reports.

It's YOUR job to fix org problems such as a lack of resources, context, clarity, causes of inefficiency and thrash, etc.

Are you doing a bad job? Does your team need your help? They will escalate to you. You better do a good job when they do!

Learn more about this in our escalation episode of The Startup Podcast - link in the comments.

Product management is not about engineering requirements

Added on by Chris Saad.

One of the biggest mistakes that product managers make is to believe that their job is to capture and translate requirements for and into engineering.

This is wrong.

The job of a competent product leader is to triangulate a product vision and roadmap and translate it into ALL business functions - engineering, sales, marketing, biz dev, corp dev, operations etc.

Common software patterns

Added on by Chris Saad.

Pretty much any piece of software you're building needs some basic fundamental capabilities.

These include...

- Identity + Authentication + Permissions

- Data persistence + Change logs

- User Notifications (Notification tray, email, SMS, and more + end-user controls)

Can you help me think of more?

Name things - well

Added on by Chris Saad.

Never underestimate how attaching a clear name for a discrete product module/deliverable can motivate engineers to create beautifully encapsulated components that can be more effectively iterated and improved over time.

First principles > Domain Experience

Added on by Chris Saad.

Typically, you want to hire for first principles thinking, horsepower, and talent.

Domain expertise is typically a low priority or even works against someone joining a disruptive tech company.