---
title: "What Do I Know?"
author: "Carlos Oliveira"
url: "https://writing.colivetree.com/3/product"
---

Intro

Product jobs are funny. 

You'd be offended if (rather when) anyone mixed up their terminology and called you a Project Manager. 

Yet, in many ways, there's a bit of the job that's classic PMBOK project management.

You'd be on your toes if someone asks if it's like being a Business Analyst in the old days. No! It's more than that. You're in the trenches, but you're also strategic, you're full stack.

You cringe when someone calls you the CEO of the product. "If only", you think. "I get to manage the CEO so the team isn't constantly swerving left and right getting derailed."

You're sensible to people asking how you decide what gets built when you have a designer, a head of sales, a head of marketing, the CEO, all asking for stuff to get built. "Aren't you just managing those guys' priorities?"

You're asked to be a visionary but also business savvy. To think long term, but be sensitive to the growth hack that would produce an effect just now. To stay the course, but also pivot whenever the evidence demands it. To have strong convictions, but have them loosely held.

It is precisely because you have to be all of those things, all of the time, all at once, and decide which hat is more helpful to your team and the company at any point in time, that it is such a rich and demanding job - one that's definitely not for everyone.

These are reflections on the various product (and adjacent) roles I've played over my career and how we as Product folk can adapt to become the most impactful we can in any role that we play. There is no one good way of getting the job done. These are tools and models that have helped me become stronger and ever more impactful at organizations of various sizes and shapes.

They'll continue changing, evolving and growing, but they've helped me get here and will help me get there. 

This book (is it a book?) isn't perfect by any means, but I hope it does the same for you.

What are we doing here?

In a Q&A after a surf competition, a surfer was asked how she would pick a new surfboard. She said, for her, it was all about how it feels under your arm. 
Have one look at videos of surfers picking out new boards - they all do this. They place the board directly under their arm, walk with it a bit, get a feel for the weight, wrap their fingers around the rail (the edge) of the board. Only after that do they start examining it up close and get a visual read on how they curve and angle. When they find one they feel will be good for them, they get their size made and take it out for a surf.

This feeling is key to a yearly staple internet series in surfing called Stab In The Dark. In SITD, pro surfers are given a batch of unidentified surfboards and they need to pick the best out of the bunch.

It’s pretty impressive, even if you are a surfer yourself, to watch pros be given a batch of seemingly identical surfboards and, through simple heuristics, immediately get a pretty good idea for who the shaper (the maker) of the board was. 

Curvature, dimensions, balance, weight, shape - they all amount to a kind of shaper signature. Give a seasoned surfer a few moments on land with a board under their arm, and they'll be able to predict how it’ll feel once they’re out in the water, board under your feet, dealing with the rawness of the ocean.

In fact, a lot of action sports are about building up your instincts and your muscle memory to a place where, even when you’re putting yourself in high risk conditions, you will respond with the right solution to the problem you’re faced with.

Accidents, injuries and long hold downs are inevitable in surfing if you put yourself out there, but your preparation will be the conditioning factor that will dictate success in challenging circumstances, and sometimes even survival.

This instinctive understanding of the mechanics is a key trait of action sports - but it also underlies most of activities that involve building / tinkering with something in the real-world. Including programming.

Fast feedback loops are part of the commonality here - trying, failing, getting that rush of adrenaline and dopamine when you succeed and an immediate sense or experience of danger and failure when you don’t. You touch, you try, you feel, you observe, you learn.

The problem, of course, is that when you build products for real people, everything starts to escape your own reach real fast. The experiences you build for are those of others, their feedback and your perception of their usage are an approximation of their own experience - the best possible trade-off between known individual experience and a sort of minimum common denominator across various modelled group experiences. Product folks use this aggregate data to model the world, and the ways in which we slice it come from a subjective experiential lens. It’s a lossy experience, like a low fidelity codec of the real world - we accept that knowledge work relies on lagging feedback with imperfect and uninstinctive response mechanisms.

When you start removing yourself from the building process and abstracting it into models of reality, which to an extent you will always have to if you want to solve really complex problems, you have to start coming up with shortcuts to identify your world-changing levers.

Some companies use data as that shortcut, that crutch - we see metric X moving in a certain direction, and that means Y, so we’ll do Z. A great many deal of technology companies use OKRs, North Stars, and other frameworks to proxy the world with data points. Inevitably that helps set a direction, identify a measure of progress, and then set sail. This of course, is a planning abstraction, more akin to the drawing up the Maritime Discoveries on an incomplete map than to the act of sensing we were just describing earlier (making assumptions about which way India is). Your new world is removed from where you are today, so you rely on a belief, an assumption, and you set your direction based on that assumption - as long as you say 27 degrees southwest, you’ll eventually reach the promised land. From here to there lies the real world experience.

Naturally, all modelling abstractions require a meta layer of assumptions - see the spherical cow problem. The goal is to not to let the gap between them and reality kill you in the process of living. Both in startup life and in the late middle ages.

I’d expect if Columbus or da Gama lived in the Age of the Internet they would have written best seller books riddled with survivorship bias. We can now ask Chat GPT to write a few chapters of those books for us.

That’s not to say usage data can’t be the clay from which we shape our models of reality. After setting sail, we have to use a mix of data and other sensing to gauge progress, observe our surroundings and orient our stead.

The coldness of the air, the temperament of the wind, the direction of the shade, the roughness of the sea. They’ll serve as your scales for risk. But your North Star will still be your North Star, even if you don’t know precisely where you are or where you’re meant to be going. There’s a leap of faith assumption in there already, that the promised land is east, past the cape of torments.

In all of these cases, the difference between life and death is often that instinctive understanding of the mechanics. It’s interpreting and acting in measured, non-catastrophic local ways, ensuring you live to tell the tale of the journey. It’s made up of lots of good decisions, a few great ones, zero terrible ones, and a healthy amount of luck.

In surfing, in sailing, in the art of motorcycle maintenance, or in product building: how do you develop that sharp sense that cuts through the fog of doubt? How do you survive your own bets through a mix of good and great decisions, while making no catastrophic ones.

In commoncog, Cedric Chin goes in depth into tacit knowledge. His series of posts is extraordinary and I highly recommend it.

I will drastically simplify it through a summary of my current understanding of the field, and how it applies to my point about building an instinctive understanding of the mechanics - one you can use every day, for all decisions coming your way, big and small.

The first stage is always the diagnosis of the situation (or situations, plural) and the context it has stemmed from. The key in diagnosis is to be able to accurately establish your circumstances. To do so, you need to be able to foresee immediate causal paths, establish clear connections between those circumstances and their potential consequences. To do that you need a set of “prototypes” - analogous or sufficiently similar knowledge that you can use to establish these causal paths. These prototypes can come to you in a number of ways: lived and sensed experience, theoretical knowledge, cross domain applied metaphors - so exposure to other sources of knowledge and purposeful reflection are tools that enable these capabilities. This is why I often recommend folks read books / listen to podcasts outside their field to improve in it, especially when your field depends on a wide ranging decision-making toolkit that you can apply to a variety of circumstances.

The second is to connect that diagnosis to a goal, or a set of goals, that enable you to succeed and thrive in that context, both in the short and in the long run. Defining those goals will require you to visualize those causal paths in enough detail that you can traverse a realistic path that maximises changes of survival, on the one hand, but also that you’re doing so in a way that optimizes for future upside. An experienced programmer, for example, knows that taking certain shortcuts that solve short-term problems may patch things up for the time being, but will cause further issues down the road - increasing so-called technical debt. They have developed a mental model for a complex logics-based game, where attaining momentary success comes at the potential expense of future outcomes. It may be needed for survival, but you understand that you’re leaving an IOU to yourself that will need to be collected later on. Of course, this instinct also needs to be put in check since it is usually accompanied by a potential for premature optimization, which Don Knuth warned against as the root of all evil.

Finding this straight and narrow path through a complex circumstance only grows more difficult then, as you understand the decisions that you need to take and the risks you need to avoid. To do so successfully, you need to recognize the contextual clues around you and understand which ones to take in and discard, classify and rank them, and establish their likelihood of producing a certain outcome. In highly volatile, complex environment, recognizing these contextual clues, and recalling the most effective ways to address them will rely on carefully attuned domain expertise and well developed problem-solution analogies.

This, finally, opens the path to action, designing a plan, a sequence of experiments that will take you from A->Z (your set of weighed goals). At this point, having correctly acknowledged the context, set goals, and needing to decide on a plan, you need a well connected system to map goals to actions, especially when attempting to sense and predict the results of courses of action where each link may have n-th order consequences - for that you need a kind of kata, a well understood series of steps made up of hypotheses, where you know how one success leads to the next and any failure leads down a recoverable route that still enables your long-term success. Naturally, the certainty one feels in case one has drawn up a well-crafted plan is often very similar to that which arises in case of a disastrous roadmap, so unfortunately these instincts can be as deceiving as a siren’s song, and as enticing and powerful as a tsunami.

Every day I try to make sense of the dark art of being at the intersection of many different disciplines to create world-class experiences for Internet Economy products.

 ![1_YmTvZAEQSdM6IlQlCQOlaw.webp](https://writing.colivetree.com/u/1_ymtvzaeqsdm6ilqlcqolaw-9KgFtH.webp) 
2 out of 4 isn’t too bad.

I’ve battled with explaining what I do every day for a while. 

The Mini-CEO of the Product, the Good PM/Bad PM and so many other great examples have framed my thinking, and helped me come up with my own definition. This helps me understand the type of problems I solve with my teams every day and, as such, our lacks and faults, and how fundamental they are to what we’re creating.

I’ve divided the practice of Product Management into 4 operational planes.

From the ground up: a. Context > b. Hypotheses > c. Outcomes > d. Process

 ![1_zdqO4F5K0l6a7l7TJZamPw.webp](https://writing.colivetree.com/u/1_zdqo4f5k0l6a7l7tjzampw-6Ce6uT.webp) 

I then categorise each of those planes with 4 fundamental attributes:

1) The Big Question – What is the fundamental thing we’re trying to answer in this plane?

2) Inputs – What do we need to know to answer the big question?

3) Outputs – What do we get out of answering it?

4) Activities – What do we have to do in order to answer it?

So starting from the foundations, let’s move up the product manager role as I see it.

**Context**

The plane of context is about fully understanding why you’re doing what you’re doing.

 ![1_XY8Tvytf0eBaDgpImOrSNg.webp](https://writing.colivetree.com/u/1_xy8tvytf0ebadgpimorsng-AvGYoO.webp) 

Whatever problem you’re solving, you need to:

**1) The Big Q – Start with why**

> Why are we solving this problem?

Before buying a new house in an unknown neighbourhood, you need to know as much as possible about its intrinsic and extrinsic characteristics: the location, transportation options, nearby schools, criminality, amenities, does it have a garage, do people complain about the noise, is there enough parking, etc.

Similarly, a great product manager collects and explores the collective insights of her organisation to understand the context of where they’re building their product to nail why the problem needs to be solved.

Because maybe… it doesn’t.

**2) Inputs – what do I need to know**

> How do you get to know the location where your product will be built?

I’d say you need at least a good grasp of: your Organization, its Vision and Strategy, the Market, your Users/Customers, the Technology and the Business Model. Talking to people, getting out of the building, feeding off of customer research, being aware of what competitors are building and the potential business models you could explore, but also the technical possibilities and constraints you’re faced with, will allow you to make the decisions you need to make.

**3) Outputs – what have I learned**

> One of the most important jobs of a product manager is to turn the why into the what. 

He does that by compounding the insights from these dimensions, usually the domains of a business function (Growth, Commercial, Engineering, Customer Support, UX) into cross-cutting insights, quantitative and qualitative analysis and sometimes ambitious ideas that can transform the product and were lost in the noise or knowledge silos of the organisation.

The other output is your positioning. Only by fully understanding the context and why you’re solving the problem, can you clearly and confidently state what you’re building, and, sometimes more importantly, what you’re not. Ryan Singer explains it better than I could ever hope to.

**4) Activities – What do I need to do**

Research – tons of it. Company Strategy. Competitors. Market. Business Models. Lean, Agile, Kanban. User Research, Kano Studies, Jobs To Be Done. GMV, CPC, CPM, LTV, CAC, SaaS. Microservices, React, Docker, Machine Learning, Experimentation. Kubernetes and AWS. Content. Localisation and Internationalisation. SEM and SEO. You don’t need to be an expert in any of them, but you need to know enough to make informed decisions and drive insights. Talk to people, get out of the building, find out why you’re solving this problem.

**Hypotheses**

 ![1_65EYCSNdt8I_6v4Afmzs4A.webp](https://writing.colivetree.com/u/1_65eycsndt8i_6v4afmzs4a-QRQCMd.webp) 

**1) TBQ — What Problem are we solving? Is this a real problem?**

Problem definitions are usually broad, so when moving from the context plane into the hypotheses domain, we start to define what we believe in. Just know why we’re solving something doesn’t give us enough boundaries to define the problem. So we hypothesise: 

> “Based on insight X, I believe that change Y will produce impact Z”

It’s important to define the problem in these terms, because it forces us to confront the fact that we’re attempting trying to model the world with our knowledge. It’s a belief, an opinion about how the world works, based on an insight, not a statement of fact or a pure guess. You’ll be surprised at how often you’re wrong.

**2) Inputs — Insights, Ideas, Customer Needs**

The best way to collect insights is through a thought process at the right level of modelling the world. Finding patterns and similarities, analogies, weird customer behaviours, unexpected data patterns after a serendipitous piece of feedback or an interview where someone struggles with a facet of the product.

Clay Christensen said that “Questions are places in your mind where answers fit” — be curious enough to find the unexpected insights and brave enough to put them to the test.

**3) Outputs — Solution attributes, Acceptance Criteria**

> “We will test this by assuming the change has no effect (the null hypothesis) and running an experiment for 1 week. If we can measure a Y% statistically significant change in [metric] then we reject the null hypothesis and conclude there is an effect.”

This is the standard hypothesis evaluation mechanism. The goal is not to get it right every time, but to scientifically understand what we want the outcome to be. How we think of success might change over time. but it’s essential for us to be able to extract focus out of our experiments. As we move up the planes, the picture should be getting clearer. By failing to see the effect of a given hypothesis in an experiment, one should use that to refine what the solution should be. Similarly, by seeing an experiment succeed, one should not rush to think he has conquered the world, but merely been able to establish a causal relationship between an insight and an outcome.

**4) Activities**

Experimentation is the tool of choice for the hypothesis plane. It’s not (just) about building MVPs, though. JTBD interviews, Design Sprints, rapid prototyping, ODI, applying the Kano model and other types of user research can prove or disprove a hypothesis.

If you can’t quantify your outcome and are still in qualitative land, define what you expect it to be upfront. This is a tool to fight confirmation bias and avoid only seeing the results you want to see.

What if disproving your idea could take only 5 seconds?

Find the activity that‘s right for your problem. The goal is to really understand it.

(For a handy list of human biases, do check this out.)

**Outcomes**

 ![1_Vchi7DOHYdFnOU73ypeVBA.webp](https://writing.colivetree.com/u/1_vchi7dohydfnou73ypevba-zPw8Ro.webp) 


**1) TBQ — How will we know we’ve solved it?**

The next plane, when the hypothesis has been properly defined, is the plane of outcomes. How do we know we’ve solved a problem we believe is real? Will we consider our job done when we develop a cheap MVP that does the trick? Or will we iterate on it until we’ve found the local optimum? If there’s another maximum elsewhere, will we attempt to find it? How can we avoid premature optimization and building a death star?

The question is how we define success for ourselves. What’s our exit criteria. It’s turning the attributes of our solution into goals we can track.

**2) Inputs — Solution attributes, acceptance criteria
**
Knowing the hypothesis clearly, you want to formulate preliminary acceptance criteria that will validate it. What’s the Riskiest Assumption to Test? What are the primary attributes of that assumption? How do we design them to be understood? What’s the impact we need to see on user behaviour to accept them – Our Overall Evaluation Criteria?

It’s natural to start with a set of attributes, but not have value assigned to them – no exit criteria. This is where you need to manage for outcomes.

**3) Outputs — Metrics and KPIs, Lessons learned
**

Define clear attributes for success.

Let’s say you’re introducing a friend discovery service to optimize on-boarding in your social network. What’s the impact you expect to make? Are you measuring leading (number of friends added in X days) or lagging (retention, engagement) indicators – have you established a causal relationship between them? Do you know what effect you need, to obtain statistical significance? If you go from 5 to 6 friends in 7 days, does that make a difference in your star metric? How about 5 to 8 friends? 5 to 10?

Managing for outcomes means understanding what the solution needs to deliver and what are the key attributes it needs to possess to deliver them.

**4) Activities
**

Using the hypothesis kit above gives you the minimum expected impact you can measure. It still doesn’t solve the issue of statistical significance vs product significance. One can work for a year to deliver a 0.02% increase in conversion rate. Was it worth it?

Define realistic stretch goals — watch Rick Klau’s OKR presentation for some guidance. If you need a 5% increase to deliver impact on your star metric over the course of year, but it’s likely that your product increment won’t be able to deliver anything over 2%, set your goal at 2.5%. Force your solution to creatively validate your ability to achieve the end goal, without demoralising your team. The OKR principle of 70% achievement is always a good start. Managing for outcomes means really understanding the metrics and how the solution will deliver them. Don’t sell your efforts short. Drive the impact.

**Process — or how we Get Things Done**

 ![1_bX_P0ifa7hACIUL-MU2yPQ.webp](https://writing.colivetree.com/u/1_bx_p0ifa7haciul-mu2ypq-ktVIdQ.webp) 

**1) TBQ — How are we solving it? When are we solving it?**

A lot of Product Managers decide process first, and then let that drive the outcomes. I argue process is an important plane to manage in, but it should be driven by the outcomes you want to achieve.

Additionally, these top 2 layers are where a lot of Product Managers get stuck. They focus on Outcomes and Process without really understand what or why. The backlog is perfectly groomed, Story Point delivery is 20/20, so they produce beautifully crafted roadmaps. But when we look back on the impact of what we’ve delivered, we haven’t moved the needle at all.

Did you really need a Product Manager for that?

That’s not to say these aren’t important. Giving your team a sense of progress, predictability and purpose are what you want to draw out of process. Setting clear deadlines allows us to manage scope, provides autonomy, stimulates mastery and creativity and manages expectations.

**2) Inputs — Metrics and KPIs, Constraints, Lessons learned
**
How do your outcomes plane inputs affect your process? Easy. Say you need to validate a major feature piece. You’ve been given 6 months to prove it’ll deliver the impact and you’ve now understood what’s realistically achievable.

So let’s start using Sprints because that’s everyone uses in the company…

Huh… Please don’t. Or do. But think about it.

You have a time box, you understand your constraints, what has worked and what hasn’t, what your team is and what the success metrics are going to be. Now is there a way to cheaply test the assumption? Can you spend 2 or 3 weeks rapidly iterating on prototypes? Can you go from no-set-process to Kanban, from no-estimates to t-shirt sizes? I believe you can, and you should, depending on the degree of risk and uncertainty associated with what you’re delivering. If the basics of your assumption are wrong, use the process to your advantage. Once the road ahead of you becomes clearer, re-evaluate and do it again.

**3) Outputs — Roadmap
**
A backlog, a set of milestones, a way of working. Operational principles. The ceremonies. The social days. The deadlines.

All of these are designed to let your team advance towards the finish line and deliver something. We are only human and like to be rewarded, recognised and appreciated. Delivery is a reward in itself, but only impact makes it long-lasting.

**4) Activities
**
There are many product ownership books and courses out there focussed on process. How to groom your backlog, how to estimate your feature cards, how to set deadlines, how to run reviews and retrospectives. How to identify the constraint and guarantee flow. There’s no need describe at length what the plays available are. Make sure your process fits the team, make sure the team understands why the process is a means to an end. Make sure you remember that progress isn’t impact, but should make it easier for you to get there.

**Conclusion**

Some products and features require you to manage more in some planes than others. The need to focus on each of them will also shift over time, but ultimately I argue a great Product Manager is strong in each of these 4 planes and is able to confidently move between them. Thinking about it in these terms helps me frame my job and the skills I need to work on.

If you’ve made it this far, hopefully it will help you too.

One of the most important aspects of building great product organisations is to design a system where builders thrive. A small group of well-organized, ambitious yet humble, smart and driven folks can be an unstoppable force.

For managers, that means hiring and empowering direct reports so that they fulfil their aspirations and channel their strengths in the direction of a better product, but also of building teams that are able to discover that product that changes the course of the company, which they probably don’t know yet needs to exist.

So what is it that sets great managers (those that shape a person’s career and elevate them neck and shoulders above the rest) apart from the — hard to find in and of themselves — good ones?

 ![1_wMmmo7DxNN9vza0oY4o5uw.webp](https://writing.colivetree.com/u/1_wmmmo7dxnn9vza0oy4o5uw-yjAWvO.webp) 
Photo by James Coleman on Unsplash

**Empowerment vs Inspiration**

Good managers empower their teams to achieve their goals. Great managers inspire their teams to go beyond their self-imposed constraints.

**Listening vs Empathizing**

Good managers listen more than they talk. Great managers understand, resonate, empathise and are vulnerable about their own improvement opportunities.

**Transparency vs Communication**

Good managers are transparent, candid and clear. Great managers change people’s careers by showing them what’s possible through great communication.

**Building Systems that Build Products**

Good managers structure processes and practices that get work done smoothly. Great managers structure systems that build products, where people feel empowered by the boundaries and can use them to uncover 10x improvements to the current product.

**Safety & meaning**

Good managers make people feel safe and productive. Great managers make people feel meaning, purpose and energised about coming to work.

**Turning impact into strength
**
Good managers care about their direct reports on a personal level. Great managers have a deep level of empathy for everyone around them and create long-lasting bonds from potential conflict.

**Crafting the strategic narrative
**
Good managers can talk comfortably about macro strategy and minute execution details. Great managers craft a compelling narrative, where direct reports are encouraged to participate actively. Their input reframes conversations in decisive ways.

**The compounding value of relationships
**
Good managers regularly check-in with their teams and direct reports and have a list of things they are obstacles and pains they are working through right now. Great managers ensure the value of those sessions compound over time by keeping a longer-term log of what has worked, what hasn’t and what keeps coming up despite our best efforts.

**Specific & Actionable Insights
**
Good managers help their people overcome difficulties and become better at their jobs. Great managers are specific about how people can improve, and analyse the problem through the lens of personal challenges, stories and goals.


Originally published Sep 30, 2018

It’s not uncommon to hear that most problems are people problems. I recently heard someone in product management say that 90% of her time was spent solving the people issues that got in the way of shipping.

How do great organizations solve this?

How do you minimize friction, streamline decision-making, and develop a culture of strong, yet weakly held, opinions, which need to carry the burden of proof?

 ![1_G5MlsIt-SomxIQHo-A7lGw.webp](https://writing.colivetree.com/u/1_g5mlsit-somxiqho-a7lgw-67Z9se.webp) 

**The more the merrier**

When starting, you find yourself in a one or two people show, running the business, calling all the shots and figuring out what comes next. You talk to prospective customers, you test stuff out with your friends, family, and acquaintances, you find creative ways to build out the next thing you think is going to make a difference and pay the bills.

You and your business partner have taken time off the safety of your previous jobs, it’s your money on the table and you both need to do, or die. When misalignment arises in these early days, it will usually spell death, so there only 2 ways out. Either both get in line, or they get out.

This isn’t to say that you’re not going to make an insurmountable amount of mistakes or that you won’t disagree on what to build. It just means that because you’re both rightly incentivized to make smart, cheap, reversible decisions until you’ve guaranteed product-market-fit, you’re forced to operate in discovery mode and accrue gains faster than you’re running out of runway. That’s the sole goal.

As you scale, though, you need to draw up an organizational structure. You create functional/specialist responsibilities, you set up management structures and knit an intricate web of incentives, local optima, personal motivations, punishment and reward mechanisms that, even in the best of cases, will create tension, friction, and personal stress. This intricate pattern of individual behaviors will create a complex system that, if you’re not careful, will likely produce highly undesirable outputs.

So is it possible to get back to hyper-alignment, obvious criteria for decision-making, shared spidey-senses that spot risk at a distance, and where the only way to go was up?

**Aligning locally
**
A large number of organizations have moved into a local-maxima optimization model. They’ve consolidated functions (think devops, UX, data scientists) and created x-functional teams that are accountable for their own outcomes. They need to work with the org to set their goals, but then are left free to roam the space that they’re given and go crazy in optimization mode.

Having multiple functions under the same goal removes a lot of the stress of individual/functional handovers, increases the length but decreases the cost of different functions transacting (more on this in a later post) and provides a great startup-like criterion for decision making: Will this move our needle in the right direction?

Highest Paid Person’s Opinion Syndrome is easy to avoid locally, as long as you have a mechanism to assert truth. Experimentation, impact assessment criteria like RICE, design sparring, believability-weighted voting, and peer reviews are processes one finds to align people behind any specific tactic when they’ve already bought into a goal.

**Aligning globally
**
Bigger issues come when people need to align globally. Whereas it’s easy to give teams a mission, that’s a lot harder to do when teams are in different departments, locations, have somewhat-conflicting goals (e.g. acquisition vs conversion vs retention) and lack the mechanisms for truth-seeking at scale. This leads to a lot of escalation and very little progress on any front.

Companies begin to feel like they need to be in sync, and precious time and customer value is wasted while internal struggle ensues. Two common avenues for this to happen are when alignment is required between functions, and when alignment is required between units.

In a functional organisation where there aren’t clear decision-making frameworks, each function tends to over-optimize for their own goals, introducing waste and costly delays in unnecessary circumstances.

Product will want to avoid rework and maximize impact so they’ll produce lengthy, prematurely defined specs, which are then taken over by design/UX. These guys produce extremely polished solutions that are overly complicated to build. Engineering then takes over and optimizes prematurely, solving scalability and reusability problems that are yet to exist and hand over to release, who fit it into the lowest risk slot in their calendar. When examining outcomes, Data Analysts will then want to be extremely certain about what they’ll report back to the business as the result of the initiative, again increasing the time to inspect, adjust and adapt.

Even worse problems might arise from unit organizations trying to tackle joint problems. Often organized around features or business goals, whenever the need to interact with others emerges, teams are poorly equipped to decide together. Taking the path of least resistance, two types of cultures often arise: 1) an “ab test everything” approach, which erodes alignment and leads to Frankenstein products and experiences that follow Conway’s law to a T, or even worse, 2) an “escalate everything” approach where the nearest common boss decides which way to go and agency is removed from individual contributors and middle managers.

The truth is somewhere in the middle.

**Evolving cultural traits
**
The first step should always be a consensus approach, where people agree on the right way to assert the truth about a hypothesis and approach designing a solution together, openly encouraging dissent and unabashed, even if inclusive, candor. It helps to have fewer, rather than many, goals, across the org at any point in time. Strong principles, widely communicated and believed, help people get to consensus.

If that fails, even slightly, each party should present their Bayesian priors, based on observation, evidence, and previous results, in order to make believability-weighted decisions.

If that fails, they should design an experiment that tests their hypotheses. They should let the data do the talking, let customer-first observation and revealed preferences make decisions.

Only when that isn’t possible should escalation be the process, as a last resort and a signal to the organization that better mechanisms need to be designed to work in the trenches.

**“Quod gratis asseritur, gratis negatur”
**
In any circumstance, the ability to challenge, dissent and compete healthily should be an intrinsic part of the product creation process. But what is freely asserted, should be freely denied.

The Latin proverb that withstood Lindy’s test of time holds for today’s companies more than ever. It is unhelpful to engage in duels of opinion, purely grounded on instinct, vision or authority. Opinionated disagreement is useful if it can constructively be built upon.

Quarreling indefinitely over reversible, non-consequential decisions is a terrible use of people’s time and erodes trust across a company, making every subsequent decision incrementally harder than the former. Lack of clear criteria for decision-making worsens the problem.

Finally, people involved in the decision-making process need to own a stake in the outcomes. If any one person is able to block or tie-break a decision without any accountability for the potential costs of their intervention, that is an important design flaw. Skin in the game promotes group cooperation and fosters altruism.

Hitchen’s razor should always be on the table.

 ![1_xIRRrzPtsDh6AHIAwLXaXA.webp](https://writing.colivetree.com/u/1_xirrrzptsdh6ahiawlxaxa-qJoCWW.webp) 

Published on Feb 9, 2025.

You're trying to get some work done, as usual. Maybe you're putting a document together for your investors, maybe you're defining the requirements document for a feature, you're shaping up the technical architecture for a new component, you're doing financial analysis for a stock, writing a bit of marketing copy for your new ad, writing a legal document, planning a therapy session for one of your patients....

Chances are, you're using an LLM (a Large Language Model). You might still be starting a new conversation with it every time or, if you're an advanced user (you're ahead of the times), you have some custom workflows that make it feel more like a personal assistant that knows you and your past work.

To be honest, as of today, so should you. Some work is just boring, overrun, run-of-the-mill, time-consuming-task-BS. 

You're just optimizing your workflow using a new tool. We all do it, all the time. It's a good thing.

Yet, this tool feels different. First, it's getting better at understanding you by the day - and you don't have to do anything differently. But also, you can give it very little, and it still comes up with something. 

That something may not be just as perfectly unique, but you have so much work to do... It'll have to do the trick, so you can move on to the other 99 things on your plate.

Once you're tuned in to the fact that each task that used to take a whole morning can now be done in under 30 minutes, we've added more. It's jevons paradox for productivity. Our days can pack more punch. We can finally do ALL THE THINGS.

It's our very own self, on intellectual steroids. Tapped into the world's knowledge, digested and distilled, we feel that for 19.99 a month we've become infinite.

Yet what happens next to some of our work is somewhat unsurprising. The zeitgeist term for it is Enshittification. 

Doing the work is cheap and it's easy even if it loses value at the margins. Even if it's a little more mediocre. We've gotten 80% for 20%. Pareto is a proud man, efficiency gains are there for the taking, craftsmanship as a commodity. The tools cease to be the tools and they become the way. The tao. Not using them would be unreasonable, archaic, unproductive, borderline unprofessional.

Time flies past us.

Now most of us barely remember what it's like to do things another way. Our parents still do some of those things, acting as if time isn't of the essence. You hear that in Japan they still do thinking retreats. Quirky mofos.

We've grown so accustomed to outsource our entire thinking process, that most of our work is condensed into pitching what we want out of the machine. The outcome is dissatisfactory but fast. So convenient. It's Uber for thought. It's easyJet's "please cram your entire ego into this lifeless measurement device because you decided to fly for cheap", but for applying to a job where your manager is a robot. At least they sound like one.

It's all very streamlined, there's no back and forth. 

Yet, it fucking sucks.

We'll erode the little edges and rugged bits away from every experience, no friction will be left. It'll all be accessible to a lot more of us. Yet the middle will collapse, and top end privatized. Many things will feel a little shittier. We'll have a hard time figuring out how we arrived at a highly Tetrapak'd, IKEA'd and Doordash'd AI-powered version of existence. At the time of my writing though, there's no turning back. It'll take years, but it is coming.

The great outsourcing of the mind has begun, it's just not evenly distributed.

Now breathe. There will be great artists still, great architects, great software developers. Lots more people will be able to play at the edges of these and really every other discipline. Many more people will be coding, or directing a machine to code on their behalf. Just like many more people can unclog the pipe under their kitchen sink when only a half-dozen variations exist in the developed world. 

But just like in the plumbing example, high accessibility and low friction at the entry point means few of us ever feel the need to venture past the hallway of knowledge and into some midly obscure room of average technical complexity or craftsmanship. The many small wins catalized by the a few unthinkably large ones. 

Does the bone structure of our society hold, in order to keep us together?

We don't know, and some of those in power don't care. That's the Dorian Grayesque beauty of optionality.

For you (who are reading this), and I, who am writing it, it seems like this belongs in the pessimists archive. 

That's not my intention at all. I think there's a version of this where we're all much much better off. Where we take the cost reduction and apply it to solve the world's most pressing challenges, simply because they've been taken off our bureaucratically politicized hands. We need to harness all the freedom, the computing, the man-hours spared by robots, the never-before-seen efficiencies to design a better world. A more beautiful, empathetic, inclusive and welcoming world. A more generous, more forgiving, more truly-connected existence. 

We won't do it by ignoring the perils and simply powering ahead. We also won't be able to stop the train or even delay its progress. We need to ride it. If there's a massive wave coming at you and you're afraid to stand up on your surfboard on time, you'll be sent over the falls, and you'll be under for a long while. You better know how to hold your breath.

We can look at enshittification and the great outsourcing of the mind in 50 years and file them under pessimism of the times. 

I want my daughter to be 10x happier, more fulfilled, more humane than I ever could be. How does this tech help her become that? How does it help us build a future for kids around the globe that take them to another age of abundance beyond what we ever conceived possible. 

It's up to us to bet on them. I recently heard Patti Smith tell Julia Louis-Dreyfus about the clarity that comes from looking at issues through the lens not of the various camps and factions involved in an issue, but of the children being impacted by it. 

There's tremendous clarity in that notion. If, like me, you're building with AI - are you building for the children?



Originally published August 18, 2022.

The other day a good friend was pushing me to give The Leftovers a chance, a 2014 TV show where 2% of the population suddenly vanishes. The series is about the impact an event like that has on social conventions, human relationships and the individual psyche. In a world where people believe others may simply vanish inexplicably the next day, there may be little shadow of the future to be concerned with - you simply can’t trust there will be a future for you, your loved ones, or others that cross your paths. Of course some will still persevere and keep their humanity, with themselves and others, but no ones keeps going unscathed.

A thought experiment my mind jumped to, was to think of a world where suddenly all our musicians disappeared, all our writers, or all our physicists. What would it mean for all of us, if any of the pivotal foundations of our culture or of our knowledge, simply collapsed overnight.

Sure, we could relearn things, we’ve built semi-robust systems of information storage and retrieval, but how many decades would losing all of our domain experts set us back?

And what if all the software engineers disappeared? Or all the product designers?

Everything around us is growingly powered by software. Software engineers are scarce and as a consequence some of the best paid workers of our generation. If there’s no one there to maintain our utilities’ software infrastructure, to keep the products that allow us to stay connected working, to transact with brands or between brands all over the world, to keep our accounting on track, know when the next flight is, operate that flight safely… how long until things would start to fall apart? How long until we put them back together?

What if all the Product people disappeared?

Of course if you asked this question to 100 PMs, they would all run in different directions depending on the size of their ego, their sense of relative importance relative to their organizations, and where in the impostor syndrome lifecycle curve they are at that particular point in time.

However, that’s not what this reflection is about. It’s about pondering on the actual counterfactual of our existence. What if there was a sudden impossibility to having PMs within our software teams. What would actually collapse?

All product managers know we’re super important. We all know without us terrible decisions would be made across the board. Stakeholders of all walks of corporate life would be preying down on engineering teams with their poorly formed ideas and HiPPOs and lack of understanding of the unique idiosyncrasies of building software. Right?

Maybe. That’s not how a lot of the best products are created in the a startup microclimate. Small teams with people working cross-disciplinarily have built amazing things before they hired a single PM. Apple, Stripe, Facebook, Google, Airbnb, Pixar, Amazon, the list goes on.

How did they build amazing things, why did they succeed, and why do the ingredients and human interactions that led to their success end up diluting into a sea of process - and lead them to needing someone or some ones, in charge of building product?

What great product people (not managers, or owners, or heads of, or VPs, specifically) actually do much better than anyone else, is to build things that make a big difference to a lot of people. So much so that someone will want to pay for it.

Very simple fortune cookie concept. Do the right things right.

Great product people look around, identify opportunities that are not obvious to others (but always look obvious in hindsight), spot areas with lots of adjacencies that drive the generation of virtuous feedback loops, are right about what solutions will actually make a difference, know exactly what shortcuts to take, the degree of reversibility of their decisions, and how to build relationships that enable everyone around them to contribute effectively. Ultimately accelerate the trajectory of the product through the opportunity space until the opportunity starts to wane.

Then, they start again.

Now, PMs usually have to do this with no actual managerial power over those they work with on a day to day basis (their engineering peers, the designers, analysts and the oft-dreaded stakeholders). All they have power over is just the shape and relative importance of the product’s attributes themselves.

This makes driving decisions harder, of course. The conditions to build great product effectively, especially when in the face of large opportunity spaces, are much easier to offer small teams who are relatively unattached to menial constraints.

That is to say: a small startup can find desire paths that shortcut any real-world constraints, by simply building.

Also: They are free to ignore all of the constraints that don’t actually impact the building process at its core. An API doesn’t exist? Build something that doesn’t scale.

(A scaled co usually identifies a dependency and goes back and forth over roadmapping and priorities)

The technology isn’t mature yet? Build it, or build something that emulates its output.

(A scaled co usually creates an R&D team with a side-product value stream or simply disinvests)

The market for it doesn’t seem to exist to most observers? Go out and find a niche that was looking for just such a thing, find someone to fund the vision, and build out from there.

(Again, easier to disinvest or create friction around incorporating into the main product, to risk compromising its core biz - classic Innovator’s Dilemma)

The ability to overcome constraints by just building “harder” is what tech companies are designed to do. So much so, that the mindset, when taken to an extreme, often produces one of two categories of outcomes: a category defining product like the iPhone or Airbnb, or a major catastrophic failure that tarnishes the soil it once stepped on: Theranos.

It is much harder to justify that type of investment in purely building (and the unrestrained decision-making process that underlies it) when you’re in a network of teams seeking to problem solve in a coordinated manner towards a set of larger goals. So forget the mini-CEO thing.

Generally, if you’re too far off the swimming current, a (generally) benevolent middle manager or executive will pull you back to a larger value stream to pool resources - i.e. let’s pull investment on that crazy outlandish idea and focus on a bigger problem, intending to make it more likely that value will actually be extracted. Generally, the PM will then be tasked with ensuring that value is indeed, captured.

So what if all the product people disappeared? What if everyone else had to absorb the role of product in their orgs overnight?

Some companies will definitely become less successful, as well as likely to succeed into the future, because the individuals in the PM roles were naturally those that have been selected for demonstrating the traits above, they do amazing incremental product work that the team wouldn’t do themselves if they weren’t there, and they rally those around them to accomplish it.

Other companies (or teams) will actually work much better without someone being a PM per se.

They will be forced to succeed by sharing and engaging in product thinking. Responsibility silos turn into shared accountability, lack of optionality means you can’t resort to you-do-you-i-do-me adn turns the team itself into the atomic unit at which product thinking occurs. While the rate of failure may go up for these teams temporarily, average product skills per individual go up, and these teams are much more likely to thrive longer term.

Product management is always a remedy to a certain level of organizational disfunction. A remedy most effectively applied where there is asymmetry in the distribution of that essential builder’s mindset that wants to solve problems for others, that craves to create something others want, a disfunction that is evolution dictates is rapidly killed in the tight sealed environment of a missionary startup (by either killing the virus or the host), but which may be an inevitability after a certain level of scale.

At scale, the number of links between any product change and its environment that need to be transversed before any release even reaches a customer is exponentially larger. Scale breeds complex systems, and complex systems are fertile grounds for n-th order consequences. Really strong product people become the stewards of problem analysis, system design and solution synthesis, as well as coordination and storytelling necessary at orgs past a certain Dunbar number equivalent.

The thought experiment then, extremely unlikely as it may be, so, is one of humility, of a need to return to the essentials of the function, of cooperative altruism, and of an evolutionary mindset. Those essential product traits must be cultivated both at the individual level, as well as at the team level.

We’d all be better off if we knew that if every Product Manager disappeared, what teams would miss, at the end of the day, would be the help of someone who embodies that customer-focused builder mentality on a day-to-day basis, and who helps everyone else embody them too.

Originally published Mar 1, 2026

## A familiar question

What should you build when everything is possible? 

How do you build when everything is possible? 

> In another moment down went Alice after it, never once considering how in the world she was to get out again.

People today are throwing _vibe coding_ around still like it's a dirty word. It was actually not meant as such by Karpathy when he coined it - he, himself, one of the great minds behind the current technological revolution. It was meant to be described as fun, light, somewhat careless coding. A return to having fun with code rather than spending weeks planning something that most times would turn out inconsequential. Either because it didn't work, or because nobody wanted it. 

LLMs brought vibing back, and it _horseshoed_ in two groups of very different people who were aching for a simpler time. On one end of the spectrum, those for whom coding was like dark magic. Impossible to approach, yet mysteriously powerful. All of a sudden someone had invented a way to cross the threshold and a gleaming light revealed itself. You just had to talk to it and there it was, invented. 

Very quickly companies were being born, bought, pivoted and scaled. Cursor, Windsurf, Cline, Lovable, Replit. Come follow us down the rabbit hole, and we'll make your wildest software dreams come true.

These companies often struggled with their ICP (Insane Clown Posse as a friend calls it). Who is it we're going after? The wide-eyed amateur, the professional dev wanting to 10x? The Technical PM? The designer wanting to push code? The Engineering Manager / Architect who's been craving to get their hands dirty? 

The horseshoe can fit everyone.


## An unfamiliar feeling

For me, things felt very different immediately. 

Throughout uni, I had struggled with how much time I'd spent browsing shitty docs for systems I knew I would likely never have to or want to operate again. 

Oracle whatever the hell, Sun Microsystems go figure, holy shit the late nights fighting shit when even stackoverflow wasn't there to help (and what a blessing it was when SO started to come alive with people).

Things had gotten drastically easier over time, but with ease came creeping complexity. Frameworks, abstractions, Virtual DOMs, Map-Reduce, Spark and Kubernetes, paradox of choice, millions of technological camps battling each other for relevance, trashing each other's solution for views. 

How is anyone supposed to get anything up and running these days? 

There was some twitter debate (aka flame wars), mostly triggered by the unparalleled indie success of Pieter Levels, with one camp arguing for the status quo. The level of abstraction and the prepared-for-everything attitude of the modern toolkit on the one hand. The just KISS, I run everything in a single server and mostly one file, attitude of Levels on the other. 

Both sides looked completely intractable to the other.

Then, things started to change. 

The next big thing in technology came, and it started off looking like a toy.


## Everything looks exactly the same until it looks completely different

ChatGPT is one of the most successful consumer product of all time. Its overnight success was unprecedented and just an acknowledgement of how the interface was perfectly right. For the time, for the need, for the use case.

What if whenever you wanted to know something (ANYTHING!) you could just... ask?

Of course, that's when the word hallucination penetrated the zeitgeist. It sounded plausible confident even when it was perfectly wrong, it kept its composure when corrected on critical details and was perfectly content with changing its mind on a whim if you directed it that way. People started testing it for work, for play, for coding, for research. It wasn't perfect, but it was fun. Especially if you didn't stretch it too far.

Some of us tried to push it. We knew there was a point at which it broke, but we also knew we could design strong enough harnesses around it that we could make things others deemed impossible given the state of technology. Certainly, there was something of a leap of faith. We trusted models would get better, we had seen them get a little bit better with every release, and we thought this could go all the way.

As with every bit of emerging tech, things seemed to plateau for a while. That made the non-believers trust they were right. 

See?, they pointed nonchalantly. Told you it was a toy.

Maybe it was, everyone else doubted. Maybe this is as good as it gets. Even if it is, we're more productive than we've ever been so that's not bad. 

Yet, imagine if it isn't? Imagine this keeps getting better and better, and better.

We're at a point now where things have gotten A LOT better. There was certainly an inflection point at the end of 2025 where models started to code well, spend unreasonable amounts of time on tasks, get a lot of hard things right, plan and do better with uncertainty and a higher degree of freedom and act more responsibly with destructive behavior.

It still feels like early days, but the few people I've seen get productive with the tools now ship more than 20 / 30 people, and even certain 100 people teams. They ship usable software, more ambitious ideas, crazy high fidelity designs and design systems, complex hard-to-orchestrate systems. The infrastructure will only get better, and with each iteration, so does everything that uses it. Knowledge work and then all work, is on the line. 

I don't know where this is all going, and anyone that tells you they do - is bullshitting you. Our guesses are as good as the future says they will be, and the self-fulfilling prophecies they contain will often be true, but only to some extent. What I do know is that we need to keep building. If we build great things, and we build with genuine care for others, the future will be better off for them.

Plus, it's great fun.

Working With Other Humans

Originally published Nov 4, 2019

 ![1_l0bc2HiMXVqdp2hyxgRc_A.webp](https://writing.colivetree.com/u/1_l0bc2himxvqdp2hyxgrc_a-hpiUzJ.webp) 
> Forecast like you mean it — https://xkcd.com/1606/

Why do we so often ask teams to estimate in detail how much effort is required to build a product, and to that upfront? There’s evidence that this lead us to output-oriented thinking, premature optimization, bloat and generally a commitment to suboptimal solutions that are designed with too many assumptions and a lack of clarity on the problem space.

Yet the main reason, I’d argue, is that estimation is an entirely rational risk mitigation strategy. Some of the reasons might be that:1) we’re promising to build a product for price X, when it’s going to cost us more than X-M, where M is our minimum acceptable profit margin. Maybe we don’t want to build this thing.

2) there are explicit and irreversible costs to not meeting a deadline and we want to minimize the risk of not doing so, so that we can organize and dedicate appropriate resources to it.

3) we are uncertain of the returns it will yield, so we want to be sure that we’re not overinvesting vs what we have in the bank.

That’s all fine, but I argue that diminishing returns to estimation happen pretty early in the effort scale, and discount your ability to respond to future ambiguity. 

Teams should focus on simple, transparent budgeting, asking themselves a few key questions: how much runway do we have to build this? E.g. a start-up may need to get a particular feature out the door in about a month to test market appetite. 

A scale-up might need to deliver a big product stream within a year to capture the returns of that investment in the next financial exercise.

How much of that runway do we want or need to bet on this particular problem? Is it a bet the company move? Are we hedging our bets with 3/4 major plays? Are we just seeking initial validation?

Do we believe we need to acquire additional resources in order to fund these goals? Why? Is there anything we could drop instead? Do we know enough to make the decision?

**Clarifying Runway**

Teams should be formed and funded to solve a specific problem or need, not given a fully shaped answer. Understanding and negotiating the right runway to answer a given question upfront is an important part of the process.

Do we know the problem we’re solving well enough? 
Follow-up: How much funding do we need to figure it out? Can we meet in a few weeks to talk about what we’ve learned?

Does this look too big for our team? 
F: How do we break this down? What’s our first goal and how much budget do we want to allocate to it?

Have we discovered a major hurdle or roadblock? 
F: Are we likely to run out of runway to tackle it or can we solve with the current constraints?

The right level of constraint fosters creativity, productivity, and agility, so managing your burn rate towards your expected outcomes as a team should be a fundamental part of your day to day discussions. When questions such as these arise, when you can’t solve them within the budget you have, there’s a frank conversation to be had with your investors (either internal or external), to get a portfolio take on it and use your voice in a forum where you can advocate for the right resource structure given your current level of knowledge.

If you’re estimating you need to have converged on solution and sized it to a very narrow shape. Budgeting allows you to choose what to invest in and leave room for teams to figure it out.

 ![1_ACTwcl5yM7RT9UK4qHQE_Q.webp](https://writing.colivetree.com/u/1_actwcl5ym7rt9uk4qhqe_q-BPM35h.webp) 
> If you’re estimating you need to have converged on solution and sized it to a very narrow shape. Budgeting allows you to choose what to invest in and leave room for teams to figure it out.

**Betting**

Now when you’ve worked out your current runway (give us 3 months to work on this), it’s up to you as a team to decide how best to use it. People should share a stake in outcomes, so that they’re accountable and responsible for their achievements.

For simplicity’s sake let’s take money out of the picture. You have 5 highly qualified team members and 12 weeks of runway. Each team member gets 12 coins, which they can spend as they please. They can use it for experimentation. They can use it to solve technical debt. They can use it for foundational work with a longer payback period. They can manage their ROI horizon so long as there is team buy-in. As a team, your communication becomes about whether you’re using your runway the right way given the problem you have to solve, how much do we believe in our solution, how much evidence we have to back it up, and how to we maximize our personal time investment.

A great product manager maximizes this ROI function for their team. They devise the right investment strategy proposal, offer their teams the right level of information so they make informed decisions and good trade-offs, and continuously evaluate and communicate said strategy in the presence of new information — did we get results back from users? Are we becoming more confident about the value this represents?

They also let others take the lead and own solutions, emergent problem exploration or resource allocation plays, devoting their time to synthesising the outcomes into a good map of where we’ve been, what we know, and where we’re headed. 

Are we getting bang for our buck?

**Funding**

Finally, acknowledging that you need funding as early as possible in the process, whether it’s in the shape of time, money or both, is important. 

“Gotcha!”, you’d rightly say right about now. 

In order to know whether you need funding, you’d have needed to estimate whether your runway is sufficient to meet your goals. I don’t disagree. 

I argue though, that accuracy gains in product development estimates are quickly offset by the time and cost of those gains, particularly for complex problems where you have too many unknowns and need to make up assumptions to move forward. You should be making a continued assessment based on risk and reversibility while reducing unknowns and assumptions using a diverse set of viewpoints and tactics. 

Set your ego aside and ask honest questions, be open to change, be confident enough to bet.

**Reviewing and Restructuring**

Once you start budgeting and funding, as you become better at breaking problems down, identifying key assumptions, incorporating new information, assessing risks, potential returns, modelling your predictions and even improving your productivity, deep and detailed estimation will become much less important, while systematic flow will grow in relevance. We’re able to define bite-sized chunks of our larger meal, and use what we’ve learned to move forward in the right direction, gaining momentum.

Keeping a healthy bets portfolio and shipping consistently against it becomes ever more important and reviewing your investment strategy often, understanding the shape of each of your investment’s returns, is a fundamental exercise.

At a portfolio level, organizing teams in relation to the structure of your needs, your runway, and your risk level becomes the better lens through which to look at the world and gives individuals the authority to go out and discover the best solutions to your current problems, especially with healthy and regular feedback mechanisms in place.

**DevOps is dead — Let’s be DevProds**

Originally published Apr 19, 2015

We’ve seen the move from a programmer plus operations culture to the emergence of the DevOps culture. The start-up movement, where small teams rule, the emergence of tools that allow developers to set-up complex infrastructures easily, others that allow developers to create powerful automation and configuration scripts and the recognition that small, empowered teams can accomplish great things, were all factors that brought together the IDE (or Vim ☺) and the shell, and let developers expand their reach. The DevOps culture had risen, creating a lot of opportunities for these newly created unicorns.

This small step was great and brought a lot of flexibility and power to teams. Combined with cheap and easy to set up cloud services, actual miracles happened.

**DevOps is Dead. Long live DevOps.**

So now it’s 2015. We’re happy, we’ve settled, we’ve accomplished a lot and we should congratulate ourselves.

DevOps worked.

So let’s move on. Let’s kill DevOps.

Let’s create DevProds.

DevProds are developers who believe their work extends far beyond the lines of code. When their work is in the hands of actual users, it’s only getting started. Actually, forget about “users”. Their products end up in the hands of people like you and me, but they also end up getting to people like our parents, our young cousins, our older friends, our friends who “hate computers”, our sister who has a smartphone on her hands 24/7, but couldn’t code to save her life.

DevProds know this and they’re not settling for less. They don’t just code for the backend, they’re not just writing APIs or libraries that “no-one will ever see”. They know they’re doing what they’re doing to make an impact. They’ll leave a mark.

**Meet the DevProds**

So, are you a DevProd? I’ve written a quick guide to help you figure that out.

**You’re Product-focused**

You know your product inside and out. You know why your team decided to build that feature and why that other one is sitting in the bottom of the Backlog. You understand why that component needs to scale and the other will never be a bottleneck. You know what your next priorities are, when users are leaving and why, how many are staying, whether they’re engaging with your platform like you’d like them to, what’s their lifetime value, what you need to do to increase it.

**You understand requirements / Stories / Flows**

You understand your customers needs, you know the hypotheses on the table, you want your product to succeed. You want it so hard, it itches. So it’s not a big deal. You can put yourself in your customers’ shoes and translate their pains to technical requirements, User Stories, UI Flows and even paper prototypes. You can look at them and understand how they affect the bits and bytes, the gear wheels, the code you write. You know what could demand a graph search, a NoSQL or a column-store database, a message queue or an API that can be easily extended to encompass what your product might need next.

**You need Continuous Deployment**

You are a DevOp at heart, or at least you know why you need Ops. You need them to maximise satisfaction for the people using your product. To make sure that happens, you have to put quality into everything you do. You need the assurance that if you find something’s wrong, you can fix it one minute and have it in your users’ hands the next. You need continuous deployment. Not because everyone else is doing it, but because that’s the only way everyone will be committed toward the same goal and your users will always be experiencing the excellence you want them to have.

**Analytics**

You know your work begins when the first person meets and greets it. You are analytics-driven because you know you’re not always right. Beautiful code is a means to an end. There’s always something to improve. Your users will tell you what it is. If it’s not them, it’s your infrastructure, or the business process you’re working to improve. And when they do speak to you and whether they make your analytics whisper or scream, you’ll be listening.

**You’re not full-stack, you’re full-cycle**

You recognise that your purpose can only be truly fulfilled if you understand the pains of your users and how you can help. So you’re willing to be there. You would do support, you would talk to potential customers, you would lead the definition of new requirements, you would push yourself and your team to do better. In fact, you do!

You’re not just a developer. They can’t put you in a box. You don’t have to know everything, so you can’t be full-stack. But you can be there for the whole cycle and make it count!

**Create a DevProd culture**

So now it’s up to you, your company, your team, to implement a DevProds culture. This means you can’t just relay the responsibility to that guy who didn’t do what he was told in the last Sprint Plan, that manager who didn’t explain the requirement in excruciating detail, or that UX designer who handed you the latest prototypes. They have responsibility, yet somehow, so do you. You guys are one, you‘re A Team (or A Tribe, or even A-Team), and to do that you will have to become a DevProd.

You’ll raise hypotheses and carry them out. You’ll review analytics and bring the conclusions to your team. You’ll talk to your customers. You’ll sell your product when you can and you’ll do support (please watch this). You’ll want transparency because that’s the only way everyone is on the same page. You’ll want office happiness because you want everyone to be engaged. There can be leaders, there’ll still be guys carrying the vision.

But you will all be building the same product.

So from one Developer to another:

Be a DevProd.

Originally published Mar 31, 2018

Humans want to put things into categories. Life is easier that way. At work, particularly for software organisations, planning often means putting your work in a box: Is it a Project work stream or an Experimentation one? Is it Engineering or Product? Is it Date-driven or Result-driven?

Having categories is great because they allow everyone to quickly grasp the fundamental characteristics of a given piece of work, without having to look too hard at the specifics. System 1 thinking will do the trick. We know that for something to be a features, for example, it needs a set of requirements. A date-driven initiative, requirements plus a deadline. Outcome-driven streams are often date-flexible, but assume a static goal.

Regardless of how you categorize, then, you’re reducing the dimensionality of the problem to make it seem understandable, achievable, ambitious yet realistic. Let’s look at some examples.

**You have to choose!**

The project management trifecta / triple constraint, which is wrong in its very unique way, for a long time provided the best oversimplification available to anyone building products or services. It boiled delivery down to its quality, cost and time dimensions and established a 2 out of 3 rule: you can only have fast and good, if significantly increasing cost is an option. 

 ![1_srBT2PA3JBhKTnFGxVpLsA@2x.webp](https://writing.colivetree.com/u/1_srbt2pa3jbhktnfgxvplsa-2x-L0C5Vv.webp) 
> There is never a way to intersect all 3, so you need to choose which dimension to trade-off. In this model you can choose the level of 2 of the dimensions, but the other will necessarily have to vary to make it happen.

Some have added Scope to this and made it four dimensions. Others still have tried to roll a more complicated (and as such less appealing and popular) dice with Time, Risk, Cost, Resources, Quality and Scope.

No matter how many variables you add to your function, sooner or later you’ll end up modelling the world into categories and then creating hard boundaries between them, rather than assuming things exist on a continuum. It’s easier to build a quarterly roadmap of features with fixed-length time-boxes than constantly having to list how their changing costs, feature set, quality assurance processes, marketing analyses and external risk monitoring might affect their delivery.

For example, a common split is between features and experiments. If an arbitrary threshold of expected-outcome-risk is crossed, organisations will stop calling something an experiment, and start calling it a feature. In the feature world, scope becomes into a largely fixed dimension that should be estimated, as there’s a set of functional and non-functional requirements that define it. This, in turn, allows engineers to estimate its complexity, which then allows managers to use a time boundary they can measure themselves against. Delivering feature, its full set of requirements, on-time, means success.

 ![1_-y3J4W8FAQpLjbLKwRSW_g.webp](https://writing.colivetree.com/u/1_-y3j4w8faqpljblkwrsw_g-vRyN0x.webp) 
> In the real world, if we monitor our expected-outcomes against the results we produced, we’ll see more of a bell curve. 100% accuracy or inaccuracy in our predictions will be outliers.

In contrast, if organisations treated that piece of work as an experiment, a way to test a hypothesis, they’d see scope as a variable to be minimised, time would be “as fast as possible” and so estimations would be kept at a very high level, just accurate-enough to ascertain whether the experiment would be worth it given their expected ROI.

Experiments also treat that as variable: expected ROI. Whereas features imply a need to build, experiments question whether it’d be worth doing so. They use the language of minimum viable products, of iteration designed to assess links of causality in order to learn about customers quickly and purposefully.

 ![1_fX9bPWBXpiar4G0WqNrvbg@2x.webp](https://writing.colivetree.com/u/1_fx9bpwbxpiar4g0wqnrvbg-2x-h830AL.webp) 
>Build-Measure-Learn cycles were popularised by the Lean Startup as the way to achieve validated learning about customers.
 
There are multiple ways of lowering the risk of your decision-making, of making better predictions, of grounding them in information extracted from past realities or cases, applying inductive theory to generalize from bottom-up observations.

In contrast, top-down strategy in high-entropy, low information scenarios such as Internet Economy companies is still assumedly deductive. We design a theory and then attempt to prove it with observations. We often call that strategy or goal-setting, but fail to make it falsifiable, so that a single negative occurrence might invalidate it.

Because top-down strategy is usually deductive and theories assumed to be true, executives will ask teams to be precise in their estimates. If a strategic action’s expected ROI is considered a low-risk variable, then naturally what matters is how fast and reliably teams can execute its subordinate features.

The problem, of course, is this is often not the case. The classic innovator’s dilemma means good proxy management decisions eventually lead to a company’s demise due to its lack of ability to respond to evolving market circumstances. The pace at which leaders/incumbents innovate is outpaced by its startup competitors. The management problem here is that companies aren’t structured and incentivised to respond to the type of change that will eventually break them, due to crystallised / ossified business-as-usual processes that were design to solve a different category of problem.

Signatories of the Agile Manifesto, of course, knew precisely that, and so do companies like Spotify, Amazon, Netflix and others are creating highly talented, highly autonomous small teams that can tackle problems at scale, even if they have to compete with others internally.

But what does this mean for a team in a traditionally-shaped organisation? It means teams will be incentivised to solve for predictability — how fast and reliably they can deliver on the Exec’s vision - not for learning and evolving to stay ahead of the curve.

The pitfall, of course is that full predictability is not only impossible in a dynamic environment, it is costly and can be counterproductive. The hypothesis is that the returns to being predictable follow an S-curve, while its cost increases exponentially. Humans are also famously bad at predicting stuff.

 ![1_bNoY4eqGdsVdTsnJoNSqfA.webp](https://writing.colivetree.com/u/1_bnoy4eqgdsvdtsnjonsqfa-0FnasA.webp) 
> ROI Chart for estimates. Y axis is resources, X axis is degree of predictability. Complete guessing, while cheap, can be harmful: E.g. agreeing to a date then failing it, can cost an organisation a lot of money. The problem of course is that trying to be extremely precise predictable can be extremely costly and offer next to zero net benefits, given the opportunity costs it entails. You need to get it “just right”.

Then there are the 2nd-order effects. A premature commitment to a timeline always involves making a number of assumptions. Variables that are inherent to the creation process will be heavily simplified: technical complexity, a deep understanding of the customer needs, clear scope, a correct measure of business impact, the right skillset and tooling, etc.

The degree of resolution you can accrue, as you get familiar with a problem, is analogous to the coastline paradox problem. There is no well-defined length to the coastline, as there is no fixed scope/time/cost/quality in any project. Because the problems we’re solving are often fractal in complexity, only by acquiring a deeper understanding of each of its underlying variables will we be able to understand how to capture its expected returns.

 ![1_c6dW8HCdRJM3igb2EtF76g.webp](https://writing.colivetree.com/u/1_c6dw8hcdrjm3igb2etf76g-gbG61a.webp) 
> Will we measure the coastline in kilometers, meters, nanometers or using the Planck length?

Treating these as constants rather than variables to be managed (as in managed chaos), will have an impact on inventiveness, flexibility and individuals’ ability to respond to change in order to provoke positive outcomes. If we believe that access to knowledge is a market-advantage that will cumulatively produce a competitive advantage, for example via data network effects, it must follow that instead of predictable, we should aim to maximise our rate of learning. Observe, Orient, Decide, Act.

**So if not for predictably delivering, how do we measure ourselves, and our teams? What are we accountable for?
**

Easy answer: Customer value. Measured by any proxy / leading indicator you can reliably find that predicts long-term customers satisfaction, business viability, task achievement, removal of friction, value proposition stickiness.

Giving teams autonomy and a goal that can be frequently challenged bottom-up is not only key to having happy, engaged people, but it’s also a fundamental trait of functioning product organisations.

Even when faced with date-sensitive initiatives (think Apple managing iPhone launches, Sony releasing a new Playstation, deadlines for regulatory compliance, a startups’s runway ending), the trick is not to settle for asking only for predictably delivering a fixed set of requirements at an arbitrary quality threshold. It is instead, to set your teams up with the budget to discover, deliver and optimize on what the right scope, the right level of quality, the correct amount of risk, the appropriate cost, to achieve the maximum possible amount of impact. Measure teams success as their business impact. Let them pitch new problems and discover new meanings and missions.

Create a process for accountability where you recurrently ask them what problem they’re solving, how do they know it’s the right problem, and will they know if they’ve solved it.

Whereas some teams are using Scrum for this (posit: 90%+ of all teams are only using Scrum to iteratively deliver on their waterfall), others choose 6-week development cycles, some use innovation accounting and others still take advantage of longer cycle times and do stop/start/continue analyses at the end of each cycle (think Spotify’s DIBB framework again).

In short, this is meant to incentivise problem-solving through evidence-based processes, giving teams the autonomy to learn, adapt and even falsify their current problem statements altogether.

It will soon become obvious to teams managing their own fate, that the best way to discover the successful outliers is to lower the risk of their bets when they have very little information, and to slowly shift to a more bayesian process when they start learning and having informed priors. They’ll begin to understand where they should be going and do better at predicting the ROI of their micro-trade-offs. Over time, they’ll also need to evaluate where they are in their development s-curve, and if further extraction will only offer diminishing returns so they can feed that back to the organisation.

 ![1_oS2DnYOa6adWpSRDWRe9Dg.webp](https://writing.colivetree.com/u/1_os2dnyoa6adwpsrdwre9dg-j9VtIG.webp) 
> Getting to an outcome is messy and you need to fail a lot of times to learn about what works.

If we acknowledge that the categories we create are inherently artificial and that amazing outcomes aren’t the result of linear processes, we’ll be better set up for success. If the goal is to maximise impact for our businesses (and hopefully society in the process), we’ll need techniques that embrace uncertainty. Chaos is uncomfortable. So is setting up the right culture to work within it. But do we have any other choice?

The ancient Indian fable goes that once, an elephant was brought to a village of blind men. They had never been in the presence of one, so as the extraordinary animal stood in front of the men, they would touch it and feel it to learn the details and intricacies of its shape.

Each of the men would touch a different part of the elephant, and would go on to describe the elephant as their experience allowed.

Those who touched its tusks, would say the animal felt hard and pointy and made of marble. Those who touched its side, and feeling a tall, rugged surface, said the elephant felt as if it were a wall. Then those who touched its ear came and said the elephant was nothing of the sort. They thought it was thin, flappy and was more like a fan.

The men argued for a while but couldn’t reach consensus. They refused to understand how others could so stubbornly stand by their (undoubtedly flawed) perspectives. They argued and some even came to blows, until one of the elders demanded they stopped and listened to one another…

 ![1_Omqc86YVsT4EX_UXa6n5Og.webp](https://writing.colivetree.com/u/1_omqc86yvst4ex_uxa6n5og-rHQoNJ.webp) 
> Source: Robert W Williams at Wordpress

**The elephant in the open space**

Nowadays, Internet companies try to organize their teams into small, self-organizing units, with all the skills they need to solve problems. Amazon is famous for its 2-pizza-rule, Spotify has squadified, Google and Facebook adopted similar models, and recorded research on ideal team size goes back at least a hundred years (spoiler alert — it’s 4 to 5). Organisations are building full-stack teams to tackle meaningful problems in bite-sized chunks in a lean way. Lean and Agile, supported by the rapid evolution of specialized SaaS, have tightened the feedback loops and eased the learning curve so everyone can learn faster. The Red Queen effect has made everyone accelerate and shipping stuff is exponentially cheaper.

However, building good teams with high collective intelligence is still extremely hard. Recent research suggests that highly successful teams have 1) a balanced share of voice per member, 2) high emotional awareness and 3) lots of women!

So in essence: you need to hire great humans (especially women). This hints at the fact that a culture of high emotional awareness and balanced team dynamics that enable and encourage members to speak up and participate is critical. So, particularly when looking at multidisciplinary teams, you’ll need to carefully design systems of incentives to make that happen.

You’ll need managers, product engineers, testers, SREs, designers, researchers, marketing folk and anyone else within 2 degrees of separation from your product delivery loop to acknowledge they’re all looking at the problem from different frames of reference. Different disciplines need to be able to see the forest from their own trees.

Team members need to acknowledge the elephant in the open space.

**“Loosely Coupled, Highly Aligned”**

If your incentive structure is too biased in favour of one function, one business unit or a set of metrics that don’t reflect the reality of your business, disfunction will take over.

The blind men who have been favoured by the god of KPIs will take the lead, disregard reports of other elephant parts and optimize for their framing of the problem. This won’t make sense to anyone else, some of your best people will stop believing the mission and surprise, surprise: they will leave.Dan Ariely tried to warn us: You are what you measure.So if that’s true, when defining what you are, listen to your people. Good strategy breeds alignment, that’s why it’s so hard. Create strong, uniquely opinionated strategic guard rails that give your people space and time to invent, create and hone their passions, without straddling them to too much specificity — leave the tactics to those close to the pitch. Make sure there’s room for individual disciplines to thrive, while providing clear goals that everyone can contribute to.

**Share of voice in team goals**

Conflicts often arise from low emotional and situational awareness, information asymmetries and/or misaligned incentives. The danger in team building often lies in failing to create strong alignment between individuals’ motivations and corporate goals.

Say your newly promoted “Head of <insert function here>” is given unbounded freedom to work through your team’s OKRs. More often than not <insert function here> will be Engineering or Product. As one of the blind men surrounding the elephant, they’ll feel what’s right in front of them, make a decision with what the information they have access to, and prioritise the set of Key Results that they can feel. They optimize for their function, background, expectations and personal interests. Inevitably, this leads to products that are either a) overcomplicated and have little connection to users’ needs or b) ambitiously designed but with little to no consideration for the long-term effects of the technical shortcuts that had to be taken in order to meet viable timeframes.

The blind men need to stop talking, and start listening. When defining goals from the bottom-up, share of voice is critical. When setting goals top-down, clarity (of targets and their reasoning) is essential to avoid teams falling into emotional traps. Ideally, your organisation should do both and inform each other.

**Personal incentives
**
Another layer of complexity in team alignment comes from personal goals. You’ll have passionate individual contributors, people managers, altruistic task-rabbits, competitive go-getters and fast followers. They’ll see themselves running the team, running a department or even managing the company. They’ll see themselves with large-payoffs that allow them to help their families, working for their dream company or just having enough time to ship their side projects alongside their professional careers.

They all want personal progress and you need to enable individuals to develop the characteristics that sit at the intersection of their individuality and the company’s goals.

When specialists sit in multidisciplinary teams, give them the ability to master their craft. Promote functional critiques, design reviews, off-sites and meet-ups (see also chapters and guilds) to allow them to cooperate, compete, evolve and cross-pollinate.

Lay the foundations for the level of emotional intelligence required to create great teams by allowing individuals to thrive. Give autonomy, promote mastery and build purpose. Enable creative confidence. Let your people go surfing.

**Trading places, competitive altruism and building empathy
**

Finally, real empathy is hard to come by. When experience offers you a framing that has worked for you in the past, resetting it can be extraordinarily difficult. Teams should engage in trading places regularly — have designers and engineers work directly together, watch each other building things and understand the complexity in the detail of bringing any idea into the world. Have Product Managers share stakeholder management hardships, involve engineers in problem space exploration, the hard trade-offs and the uncertainty in every decision. Have everyone sit down with customer service. Make data analysis and experimentation a part of everyone’s day-to-day.

Building empathy takes time and effort, but it gives everyone the confidence to reframe the problem using others’ perspectives, which is why it pays off handsomely in the long run. It strengthens bonds and builds trust through understanding, allowing mechanisms of competitive altruism to emerge. All the blind men can give each other what they need, signalling their cooperative nature to the group and expecting others to take a step back and their framing of the elephant in the future.

**Make the hard trade-offs — Use the lens of customer-centricity
**

At the end of the day, hard trade-offs will have to be made. Teams and organisations will need to decide where they draw the line, what will make them go the extra mile and what they think is not worth the effort given their circumstances.

The advice here is simple — be customer-centric. Help your customers make progress. Prioritise not what they ask for, but what they need. And be sure to keep a healthy balance between fast-paced delivery of new, innovative stuff and details that delight people.

Remember Boyd’s Law: Speed of iteration beats quality of iteration, so decrease batch size, keep shipping things that matter, together — the faster everyone understands what the elephant looks like, the better your product will be in the long run.

Keeping Your Shit Cool 

I have an interview question guide. Anyone who's run more than a dozen interviews for any particular role will have some version of this. 

There are skills you want to assess, ways of asking questions that drive better, more informative answers, and you want to have a large enough menu that'll fit the level of the candidate you're faced with, which more often than not can't really be told by looking at their resume. Mine is pretty good, because it stands on the shoulders of giants. I've copied, tweaked and polished questions from colleagues, other PMs and Product Leaders in the industry, added my own, and now I have one I'm happy with.

Here's the thing though. These help me separate a good candidate from a bad candidate. But a great candidate? One who will hit the ground running by grabbing the org by its horns, grappling with it and harnessing its energy towards a much better product. Much much harder. More of an art than a science. 

There are general things that a Product person has to demonstrably show they can do through concrete, specific examples, with outcomes attached to them.

- Are people high-agency?
- Do they know what a problem worth solving looks like?
- How do they define hypotheses?
- How do they frame solutions?
- What does a great solution look like to them?
- How do they go from solution to spot on execution?
- How do they make hard trade-offs?
- How do they get everyone on board?
- When faced with stakeholders with conflicting incentives, what do they do?

With quite literally all of these, there's a pervasive, hidden skill that you can only really parse out some of the time.

It's that people were in the trenches, helping good decisions get made locally. One after another, like lego pieces that connected make a masterpiece, they clicked an unlocked a great product. 

There was a tough conversation with a designer.
A developer who was struggling with fitting into the team and was trying too hard.
A CEO trying to cram all of their wishes into the product.
A retro where the team wanted to refactor the whole thing.
A demo where people kept insisting they didn't see the point.
An experiment that reached a valuable customer who immediately reached out on Linkedin and said we were ruining the product for them.

All of these, the PM had to successfully navigate them, use them to build conviction about the problem they were solving, polish the solution to make it better than before, make everyone else more convinced than they were that this was the right thing to do. All until the final thing got shipped and it was obvious. This was the right thing to build all along. 

Well done folks.

How much can you spend on shipping, neglecting the unnecessary, quote nice-to-have, moments of delight, before the scale tips over?

When we’re creating something new, we’re unleashing our model of reality. We do that in an attempt to solve a problem our models have detected and in our belief that perception is shared by others. On top of it all, our solution will be able to extract value from addressing the problem.

These same models of reality of course apply to software products. Our creations are cheap, tremendously easy to modify, and arguably a lot harder to destroy than any of the human constructions that came before us due to their decentralised and intangible nature. For us, technologists, there is a model of what software is, what it should look like, and what can be done with it. We work hard to bridge the margins between what we think it is we’re solving and how others will interpret its benefits.

The industry quorum dictates that the way to bridge this perception gap is to fail fast. To iterate on ideas so rapidly that we’ll fail early and fail often and thus force our dumb brains to adapt their perception. But where does beauty come into this scenario? How does polish fit? How do we learn to care about the little details that can make people fall in love with your product’s personality? When we’re just focused on learning what the next big thing is, how will we ship the joy of using our products?

Imagine that when creating something new, we’re mining bits of a precious new metal. Any time we begin to extract them, we have to decide whether we’ll deposit them on the side of delivery or on the side of delight.



To create world-class products, we need to keep a tight balance.

**The bias towards action — #alwaysbeshipping**

Existing entrepreneurship mottos have taught us we should always be shipping. Hashtags were born, great books were written, we became addicted to MVPs, cue rapid prototyping. We want to put something out there that will fail fast. ‘Failure is learning’ we keep repeating, while arguing about what’s minimum and what’s viable. Does our model of these two concepts match that of our (idealized) customers? ‘I don’t know, let’s deliver an MVP and find out.’

There are lots of powerful ideas behind these concepts. Firstly, there’s a humility that I can relate to:

We recognize there’s a lot we don’t know and we’ll only really begin to grasp once we show it to others. Maybe no one will care about this thing, so let’s build the cheapest version we can, to make sure.

Also, no one gets it exactly right at first try. Even when we are onto something, there’s so much wrong with it, that only by getting our hands dirty will we find out what that is. Experimentation might just be the real mother of invention.

Reid Hoffman, who created this little company called LinkedIn, said that if you’re not terribly embarrassed by the first version of your product, you’ve shipped too late. So we’ll measure, we’ll learn, iterate and if we’re wrong, we’ll do the famous pivot.

But in our delivery rush, we build up a debt to delight.

**Not bad, but we only deal in excellence — #pixelperfect
**
There’s another group with stakes in this game. Those who think of themselves (sometimes rightly so) as artists, artisans and crafters, who put so much thought into their creations they suffer from separation anxiety when they have to let it out and into the world.

Every last minute, they decide they aren’t quite there. No way people will enjoy it as is. Let’s just put the finishing touches on it. We want delight! We’ll only stop when we’re sure customers will love it. We obsess about the little big details, the emotion and the micro-interaction, the hyper polished version of ourselves and our solutions. Our product should be inspirational and aspirational. It should show we care and nothing less than perfection is enough.

We’re proud to say: It’s pixel perfect.

What if we were wrong? What if all our precious metal was invested in polishing the wrong solution, or one to a non-existent problem? What if we’re not Steve Jobs? And even if we are set to become our idols, was the first iPhone perfect? At some point, we’ll have to pay the debt to the delivery and learn from our mistakes.

**Balancing the scale
**
As you might’ve guessed from the title, this post is about the balance. It’s about chipping away at your unfinished product, while being aware that it’s all too easy to lean too much one way. With every iteration, be that an feature, an experiment, a refactor, a redesign, an interstitial animation or a beautiful illustration, ask yourself: What’s my current balance?

 ![1_qAWfH1MEeyqvv03trm2G0w.webp](https://writing.colivetree.com/u/1_qawfh1meeyqvv03trm2g0w-gj7TWi.webp) 

You should strive to keep your balance when creating something. If you’ve strayed too far delivering stuff without sweating the details, you know you’re indebted to delight - just ask yourself, is this product any fun now? Is it **actually** great?. On the other hand, if you’ve spent weeks crumpling your prototypes into paper balls and throwing them into the figurative product bin because they’re not ready, just ship them — learn what you can’t know and pay your debt to delivery.

This is about keeping score: Balance delivering the jobs your product needs to do, with the small things that will spark the flame of delight in your customers.

The devil is in balancing the scale.

**How to start an IoT product**

Originally published: Apr 1, 2015

So you have a company, a start-up, or just an idea that will change the world of material things. The Internet of Things presented the opportunity and you’re ready to take it!

Yet, like with any product, you need more than an idea. You need to make it happen. Here, I talk about how we design and build IoT products at Citibrain. We are focused on Smart Cities, but the possibilities are endless. I suggest you start with Postscapes’ IoT resources to get your blood pumping.

This post focuses on IoT, but we propose an approach based on lean and agile methodologies. We’re looking at creating an MVP for IoT, so this is about maximising the product’s value for your potential customers using the least amount of effort possible. So let’s start from the top.

[https://www.youtube.com/watch?v=Yd6SJxan0jo](url)

The problem

So you had this brilliant idea. The first thing you need to do is create an hypothesis. This means stating the problem you wish to validate.

Imagine you are creating a premium fitness tracker for semi-pro athletes. The problem you identified would be something in the grounds of the following:Semi-pro athletes can’t get good enough data from their off-the-shelf fitness trackers. Your market niche are those semi-pro athletes, your competition would be all the other fitness trackers.Your initial hypothesis, however, could be:Semi-pros are willing to pay a premium to have better and more detailed data on their performance.This is the first thing you need to validate. Then you can move on to which things they’re willing to pay for:“Semi-pro athletes need information on heart rate, body temperature, posture, instant velocity, reaction times and landing impact.”So use whatever you can to validate your hypotheses. Discover if your problem is a real problem. Talk to users, create a landing page, share and create content, use Kickstarter, lead your target users to your website and find out if they’re interested. Ask a lot of questions, again and again. Ask the right questions to validate your hypothesis. Only this will help you build the right features.

In the midst of it all, you’re going to get caught in technicalities, feature-creeping, an irrational fear that what you’re doing isn’t enough, suggestions from your friends and teammates to include this and that. If you’re building hardware, it’s even harder (no pun intended) — Say NO most of the times.

[https://www.youtube.com/watch?v=H8eP99neOVs](url)

**The market**

Now, you’re onto something… but does your solution really have a market? Is anyone willing to pay for it?

(NOTE: You can skip this part if you’re doing it just for fun, but having validation never hurt a soul)

Good, you’re still here. Your answer to both questions was yes, but here are a couple more:

How do you measure your market? Are there cheap ways of testing the waters? You need to figure out your product-market fit. Find out if this is your piece of that 7.1 trillion USD market.

At Citibrain, we needed to look at cities. We talked to them, we went through public tenders, we ran the numbers for the verticals we tackle and we figured out which deserved our utmost attention. Which are the problems that are making cities lose money or present regulatory challenges, which make citizens unhappy and mayors worried.

Then we look at competition. Is there any? (HINT: There always is) What are they doing? What are they doing wrong? Is there a monopoly here somewhere? (Hi, Peter Thiel!)

In the end, we settled for the verticals where we could iterate faster, be the first and, most importantly, be the best of the best. We found those to be Mobility and Environmental Monitoring.

[https://www.youtube.com/watch?v=TkxM1xuBRG8](url)

**The solution
**
Now, let’s get to work on our MVP. You need to work fast, get good feedback early and start getting revenue in the door — so don’t overdo it!

You have two options now.Do you want to build your own end-to-end solution? Our advice is that you look at the multitude of open source tools available.

Do you just want to get things going fast, with a nice, stable, cloud-based backend? There’s something for you too. Take a look at Xively, 2lemetry, Smartliving.io, or even our own at Citibrain (drop me an email and we’ll get you started in no time).We chose #1 because our goal is to become the biggest backend-as-a-service provider for IoT. So we looked at things like OpenIoT, Meshblu, DeviceHive and ThingSpeak. You should also have a look at the FIWARE catalogue if you’re into Smart Cities. Each of them has their own advantages and disadvantages, so tinker with them and see what makes you comfortable.

Look at protocols and standards, these are really important. In the IoT world, start with MQTT, CoAP, WebSockets, HTTP — for RESTful APIs — or OMA LWM2M. They should get you going. Choose wisely though, consider your devices’ (or things’) requirements in terms of battery-life, how often they need to communicate, whether they need to get and send messages in real-time or ask for them periodically, etc. Answer these, and your choice will become clearer.

If you’re more of an electronics kind of guy, the things out there will get you going in no time. Arduinos, BITalinos, Electrons, the Raspberry PI or Littlebits are examples of cheap things you can use to prototype. Ouff, we’re almost done.

**Validation**

So now you’re all hands on deck building your product. Do you still remember what your hypotheses were? Do you remember what it is that you’re solving?

**Focus!
**
As soon as you have something ready, test it.

It can be a nicely wrapped Bitalino strapped around someone’s wrist. It can be a connected room temperature and sound monitor for hospitals. Get that feedback going. You don’t need to (and you won’t) get everything right on your first try. Have a rough product on your customers’ hands. A/B Test on your landing page and on your website/app. All the tools we’ve talked about are about prototyping, getting things out there as quickly as you can and trying things out before you go into the mass market. Actors rehearse before a major play, athletes practice before a big match and product teams should release often before they decide to take on the world.

**Talk to us
**
So we’re releasing. We’re demoing beta versions of our software and hardware, we’re doing small pilots in Portugal, we’re simulating scenarios, talking to users and fine-tuning our solution. All the while we’re finding funding and working with our partners to create the next big thing for Smart Cities. If you want to join us, talk to us at Citibrain. If not before, we’ll be at the IoT Week in June, so come visit us in sunny Lisbon. Believe me, we’re listening!

I take it this is pretty common. Someone reads “The Design of Everyday Things”, has an epiphany, and then goes off to become a better designer, developer, product manager or overall person. 

 ![1_sVtfIIJPKombT6STNGtn5w.webp](https://writing.colivetree.com/u/1_svtfiijpkombt6stngtn5w-hmX4A8.webp) 


**Why is it such a good book?**

First of all, Don Norman knows his stuff. This does not read like one of those books written by people that know everything about everything. This reads like Norman’s life’s work. He has spent a lot of time thinking about good design, what great usability looks and feels like. Most importantly, he has spent a lot of time thinking about how to explain it to others so they could understand it too.

He lays it out in simple, understandable terms. He defines reference models to explain interactions between people and objects or digital products and gives practical examples of their usage. He shares his experiments, real world use cases and how he reached his conclusions. You go away thinking that you empirically knew bits and pieces of it all, yet to see it written there may still feel counterintuitive at times. If you’ve read Thinking Fast and Slow, you know how that feels.

**What will I get out of it?**

The concepts of User-centered design and the bonus fact that your design vocabulary will grow richer: The structure of tasks, making things visible, providing clear mappings, placing constraints on your product that just make them easier to use, accommodating erroneous behavior and all types of human slips as part of your product, understanding your design’s affordances and how you can use of signifiers to make them clear.

You may start seeing every interaction through the lens of the Seven stages of action. From forming the goal to evaluating its outcomes, you realize you go through these stages many times a day, every day. They may not be deliberate, they may not always be conscious, but you do — System 1 or System 2, fast or slow. You can design your product to give your users a hand through these stages.

No mistakes, just bad design. Don Norman will make you feel good about yourself. He’ll tell you that all of those times you made dumb mistakes, well, they weren’t really your fault and they weren’t dumb at all. That text message you sent to your boss instead of your best mate, that time you paid with a £50 at a self-checkout machine and left the change there, that other time you deleted all of your holiday photos and your girlfriend didn’t talk to you for days…. or even when you slammed your face into that glass wall at the office. Those minor errors or slips, they’re human nature. Good design knows this.

You’ll also get a good look at the double diamond model and revisit the concepts of design thinking in light of all you’ve just read. For non-designers or former engineers, it’s easy to fall down the rabbit hole of the solution space without properly understanding the problem. The double diamond model begins by Finding the Right Problem, something every good Product Manager should be doing when given a new problem to solve.

Finally, if you’re into door knobs or faucets, there’s a lot in there for you to think about.

 ![1_UrK6Qre4eOyVhG9BLzgaSQ.webp](https://writing.colivetree.com/u/1_urk6qre4eoyvhg9blzgasq-eNzHET.webp) 
_No need for PUSH signs_

**Why did it change the way I think about product?**

The book gave me (a former engineer and recovering solutionist) a language to think about product design. It gave me a framework to think about experiments that have failed and the many things that I’ve gotten wrong over time.

It reminded me that good products are not just reliable, they’re forgiving, they’re relatable, they remember that people can make mistakes and are willing to help you get out of trouble.

They’re born out of compassion and empathy. They’re human.


**Design Sprints in the Real World**

Originally published Jul 27, 2016

When faced with a complex problem, whether in terms of the idea itself (what), its execution (how) or the organizational or personal challenges you’ll face to make it happen (who), the processes of design thinking and lean help you remove some of those barriers through cycles of validated learning. From clearly understanding the problem to finding cheap ways of testing and validating your assumptions, you can magnify your chances of success before writing a single line of code.This is a powerful value proposition and, thankfully, many in the software industry are taking it in and applying it to their projects. It is incredibly important to iterate on your assumptions and increase their exposure to potential customers. This time around, faced with a complex problem with great potential, my team and I turned to one of the most widely known validation methodologies out there — the Design Sprint — to put our assumptions to the test.

The Design Sprint is a famous 5-day methodology to go from idea to real world testing, validating your hypotheses and your product-market fit. The book is based on the current Google Ventures approach, but the roots of the methodology go back to IDEO and the Design Thinking principles.

Before we go any further — I highly recommend reading the book. It's a great back-up for when you’re running your own design sprint, wondering what to do at any stage. As my career as progressed I've had many instances where getting to a testable prototype that gets people excited about where we're going is valuable. When I need to get **there**, I often think back to the Design Sprint and pick, choose and remix the bits that will help me in that particular context.

Here's how using it went for one of my teams:

**The good**

**#1) SPEED — The Design Sprint did help us accelerate to critical feedback in 5 days.**

We had an idea about a complex solution that would help users plan their travel. Taking it to the MVP level would probably take us a couple of months. Iterating on that MVP to get it to a point where it could be out of a beta would definitely take us a couple more. If we had just done that, we would have failed.

**#2) VACCINATING US AGAINST FEATURITIS** **— We boiled the product down to its bare essentials, ensuring we would capture just enough to make it loveable.**

This bigger idea involved a lot of smaller assumptions about how people would interact with the feature, what would help them understand it, invest their precious time on it and finally tell their friends how great it is. We discussed these assumptions and figured we couldn’t live without supporting them in our design. We were wrong and the methodology told us that.

**#3) ALIGNMENT — Sitting people down and talking about the problem will align them around its fundamentals.
**
Implementing this idea would involve people from different teams and we would need support from a bunch of others who weren’t as invested in it as we were. It was hard enough to find 5 days to sit all 7 of us down together. We had tried going over it before in meetings and ended up with 3 completely divergent perspectives of the problem.

**#4) CREATIVITY — You’ll have great “failed” ideas that you can reuse in other parts of your product or business.**

When you’re solving a big problem and you get a bunch of smart people in the same room, they will all come up with great solutions. They will share unique perspectives and attack the same problem in singular ways. Most of these will not stand the test of the 3rd day, when you need to make hard decisions. That’s OK, you might be able to use them elsewhere and stimulate creative thinking about different parts of your product.

**#5) Insight — Your “Experts” will offer unique takes on the problem before you even sketch the first prototype.
**
Your “Ask the Experts” sessions are unbelievably helpful if done right. You’ll bring in people from different parts of the business who might not usually be as involved in your everyday product discussions. Aim for diversity: We brought in Commercial/Sales people, User Satisfaction, Marketeers and even our CEO. We also brought in other Designers and Product Managers who had tried solving an analogous problem in a unique way. Their insight and domain knowledge is critical to a better product. You’ll get it before you even start coding.

**The bad/The ugly**

**The Sprint won’t tell you exactly what to do (or not to do)**

Although the Design Sprint process does a great job at trying to avoiding groupthink and design by committee it does not entirely avoid it — it couldn’t, you’re all still human.

Sometimes, what you can come up with in a day is just not enough. Some users will not have enough context or be able to abstract from the fact that they’re dealing with a prototype. That’s perfectly natural and you should understand that when interpreting their reactions.I would even argue that running a Design Sprint won’t stop you from launching a product no-one wants (unless your idea is absolutely terrible). It will definitely not guarantee your feature/MVP/experiment will be successful if you follow the process and your users sessions go well — remember the context — they’re not using it at their own pace (or paying for it!)

**Your vision matters!**
You’ll get to the end of these 5 days with a much clearer picture of the problem and the possible solution space. Your team will know what they’re talking about, understand the problem in depth and be aware of the pitfalls.

A design sprint will save you development hours, avoid lots of unnecessary meetings and prevent you from making tons of mistakes. But…

Your vision still matters! It counts if you’re solving a real problem and you’re confident it will make people’s lives better. The Sprint will ensure you’re on the right track and confront you with varying degrees of excitement about it, but won’t always be magical. You will fail to impress some people and, what’s more, parts of your idea will absolutely suck: That’s OK!

When that happens, remember the principles of design thinking. Get back to the drawing board and think again, prototype again, test again. In the end, you might have failed fast — time to pivot? — or ended up with something 10x better because you've done the work to put some shape of it in front of people you thought would care. 

Isn’t that how great products are born?

Positioning

Originally published Feb 28, 2017

That some things are more important than others seems obvious. However, product creators often forget that any solution will invariably expose their points of view.

Being afraid to see your opinions and insights voiced will invariably result in bland, grey, soulless experiences. 

 ![1_vEFHGbLvy4by4_BYA3cDRw.gif](https://writing.colivetree.com/u/1_vefhgblvy4by4_bya3cdrw-CMEO5l.gif) 
> “Here’s everything everyone has ever cared about because we couldn’t decide what we were about”. 

Not only will the result be boring, it’ll be unnecessarily confusing.

**“The Authentic Italian” — The imaginary story of a failed pasta place
**
You look around your neighborhood. There are 10 different hamburger restaurants, 7 of them call themselves “gourmet”. There are also 2 pizza places. They serve pasta too, but they’re franchises… Nothing wrong with that, but they’re really not the kind you’ve tasted on your Summer trip to Italy.

 ![1_uLi0mjqA8-ljfu7agUA0rA.webp](https://writing.colivetree.com/u/1_uli0mjqa8-ljfu7agua0ra-V1tX2G.webp) 
> Picture from urbany.net

The fresh ingredients, the sauces, the smells — the simplicity!

> It hits you: Great pasta doesn’t have to be expensive. It just has to be authentic.

You find a perfect central location and decide to just buy it. You have your savings, you can bootstrap yourself to success!

You take care of the logistics, find amazing local suppliers who can bring you freshly picked tomatoes, herbs, top quality meat and this incredible meat. Two of the most talented university colleagues you know join as your co-founders and you’re off. It’s almost unbelievable how well it’s going. People have started talking about you and you’ve got your opening night fully booked.

You thought of two mains:

The rapido lunch, with just 2 dishes to choose from (one meat pasta and one veggie pasta)

The signorile dinners, where your prime bottles of Italian wine will perfectly complement the authentic pasta experience — there will be 4 dishes for dinner every night: 2 perfectly cooked meat or fish dishes, and 2 veggie dishes.

You’re now one week away from opening “L’Autentico”.

You start to second guess yourself. 2 dishes for lunch? What was I thinking?! Only 4 for dinner? No no no… All those customers booked for your first night and you only have 4 dishes to choose from? This is going to be a disaster.

People like variety. Even the burger place next door has 20 different burgers. They’ve even introduced a tofu burger recently!

OK, let’s redesign the menu. Beef and Cod only?! No, people love some healthy chicken. A nice tender chicken is great. Your suppliers can get you some great chicken.

Oh, man, what about seafood? You hadn’t thought about seafood and now that you think about it, you had that amazing seafood pasta in Italy at that Osteria. It won’t be easy to source, but there’s a really good fishmonger two blocks away. You will just add this one.

And what about the people that don’t like tomato sauce? I mean, sure, it’s Italian cuisine, but there’s always someone who would hate to come in and only have pasta with tomato sauce available - your cousin hates tomato sauce. You build a tomato-less dish.

Seriously, what’s the point of only having two categories: meat/fish or veggies. It’s all in your mind. Your customers will like variety and you're already half way there. Let’s just kill it and have the whole range available. They could even make their own pasta dishes.

> I know, we’ll have pasta buffet for lunch!

Your opening night quickly turns into a disaster. When talking to people about what they didn’t enjoy, **they don’t tell you it’s too much choice**. In fact they can’t quite put their finger on it.

Their feedback is all over the place. It’s the ingredients, or the ambiance, or the choice of wine, or that the seafood wasn’t the best. It wasn’t bad at all, it was a good night out, but you know they’re not jumping at the chance to come back for more.

You’re forced to close, 3 months later. You’ll never know that L’Autentico had started off well. You remembered what’s unique about your value proposition and what the Italian cuisine experience offered — that’s why your opening night was fully booked. You had successfully laid out the basic principles of what you were going to try.

But then you let fear take over. You lost track of the Job you were going to be hired for, the singular experience you would provide, the first principles of the implementation. You became the 3rd pizza restaurant in your neighbourhood.

**So what defines a fearless product?**

1. A fearless product knows and is clear about what it is and what it isn’t. Its differences and uniqueness are its moat. It goes back to first principles.
2. A fearless product knows the specific problem it’s trying to solve, and all the problems it’s not. Focus on the job-to-be-done and solve it extraordinarily well.
3. It knows that not all information is equal. Dumping everything you know on a 5-inch screen (or a menu) does not help more people. De-prioritizing, hiding or even completely removing functionality and information is critical to create good understanding.
4. It cares about progress more than fanciness. It solves problems before it worries about putting on a show.
5. It always puts users first. If there’s product-market fit, business follows creation of value for people.
6. It understands users aren’t always rational. Decisions aren’t linear, they aren’t statistically or economically sound. A great product is human, friendly, empathetic, clear and cooperative.
7. It isn’t afraid to take chances. Every single startup was born from a leap of faith. Trade-offs aren’t optional. They’re the everyday job of any Product creator.
 

**What *isn’t* a fearless product?**

A fearless product isn’t data blind, arrogant or a dismissive of the importance of business models. Data is infinitely valuable, delivering incremental value is often necessary and translating your friction-removal into economic utility is critical to building valuable businesses. A deep understanding of why you’re doing what you’re doing is the foundation to every other decision you’ll need to make.

However, great products don’t try to be everything to everyone.

Don’t settle for the wrong things just to avoid trouble or to satisfy that one person who once wasn’t in the mood for pasta. Don’t be afraid to take a stance. If you find yourself constantly using edge cases to justify product decisions, you’re well on your way to a terrible product.

And what if you’re wrong? Well, you’ll find even being wrong can be fun if you do it often enough.

A guide to building better products by visualizing the end game, lessons learned from using Amazon’s Working Backwards approach.Visualizing the end game

There are many blog posts out there outlining Amazon’s approach to Product Development. It focuses on visualizing the end state before you introduce any other (often more complex) validation techniques to your ideas.

These are lessons learned from testing these ideas with cross-functional product teams.

**What’s your ideal end state? — The Press Release**

Let me start by saying I believe in product vision. Not crystal-ball-type vision. But in a belief that you are the sum of your knowledge and insights — which can lead you to visualize an end state for your product or company that’s unique to yourself and can thus go against the status quo and that of incumbents.

We used the Lean Startup terminology and called that a Leap Of Faith Assumption (LOFA, read loafer in a British accent, for bonus points). When you use Working backwards you start by expressing your vision in the form of a **Press Release**. This Press Release should be focused on why you’re doing this, what the benefits of what you’re creating will be, and who will benefit from them.

Try to answer this: How will the world be a better place for my customer once I’m done?

If you can’t do that convincingly and understandably, it’s likely you don’t have a real problem in your hands.

**Is this a real problem?**

The next step is to put that Press Release to the test. Assemble your team and let them read it. Include the skeptical senior engineer and the excited junior grad. Let them ask questions about the Press Release - Call this process the **Frequently Asked Questions** — when your product is live, this could be that section of your website / app.

Anything that comes to mind. Ask them to wear the hat of the customer.

This will put the benefits you conveyed in check. Are these problems real? Can they understand the pains of the customer? Is it clear what we will have achieved when we get there? Can they spot the cracks in your (non-existent) plan? You’re sharing a vision — is it exciting enough that they want to be on board?End the FAQs exercise by clustering the questions. Identify common themes, general pain points or areas of influence of your product. This should surface a connection to your main Jobs To Be Done.

(Remind the team that we are not our customers but we can try to understand them — this is an exercise in empathy)

**What will it look like?**

You starting going into the solution space here. If this thing is to become real, what will it look like? How can its benefits be expressed in an way people will understand it? Is it a car or a motorbike? Is it a native app, a progressive web app or, god help us, a chat bot? Is it a REST API or an SDK?

We’ve now done this for both user-facing and technical products. For the former you can sketch some rough wireframes — discuss the details, be nit picky, but don’t get to high-fidelity. Remember, this hasn’t really been put in front of users, so you don’t want to get attached to a beautiful design that won’t work. You want to find the fault lines, identify hypotheses you need to test, portray the impact you’re going to have and create a mental picture of where you’ll get to.

For technical products, create rough representations of them. A draft of your architecture, a sample response from your API, a set of endpoints you’ll expose, a data pipeline or a flow diagram for your voice-first assistant.

**The special sauce — Does this solve your problems?**

Now this step isn’t exactly described in the methodology, but I’ve used the with the teams to let ourselves be critical of the solution we’re envisioning. Pick up each of the FAQs and assign them to a part of your designs — I recommend actual post-its glued to a paper/whiteboard prototypes.

Can you map them all? Does your solution address the biggest problems you think exist? Are there questions you can’t map right now, ask yourself: how impactful are they? If the answer is “pretty impactful”, you should probably validate those first.

How will people use it?

**Finally, the User Manual.**

This one has a pretty scary name for someone (like me) who believes world-class products shouldn’t need user manuals. They should be self explanatory. However, all products will have some sort of reference, technical documentation or even a proper manual (Are you building a washing machine?) At this point, my suggestion is to just do the Table of Contents. Imagine that your customer found himself in a weird place and is now reading the help section. What will it look like? How should it be organized? Would you understand it if you were him? This works just as well for complex technical challenges.

**“Now the whole team here”**

When you’re done, the goal is alignment on the problem. You had a vision that has been challenged, questioned, you’ve identified its riskiest assumptions and even began sketching out a solution.

It’s time to get out there and start over. What’s the cheapest way to prove you’re right (or wrong)? Does the solution you thought work? (hint: it won’t) Can you identify, test and validate the underlying assumptions of what you want to build?

Your journey has just begun… But “now the whole team here” (Thanks, Drake). You’ve rallied around a common understanding of the problem. Every time there is a fork in the road, you can go back to your working backwards session: How will this bring us closer to the vision, our Unique Value Proposition?

If you’ve done it right, the whole team will be asking themselves that.

Numbers

**Building your Startup's Culture with Pirate Metrics**

Originally published Apr 2, 2016

One of the hardest parts about scaling a company is keeping its culture alive as it grows. You don’t want it to stay the same — it should evolve. Yet you also don’t want it to change too much — the core values should stay the same.

A lot of startups build their culture on perks and benefits. Brand new Macbooks, standing desks, free soda and donuts, beer in the office, Nerf wars… While these are all pretty cool, they are a gimmick. They can’t be the foundation of your company’s culture, not unless you want your culture to be as plastic as it gets. Don’t get me wrong, I love a good Nerf headshot as much as the next guy, but I wouldn’t work for you because of them.

I propose we treat our culture like we want our people to treat our product.

So let’s work with Dave McClure’s Startup Metrics for Pirates framework and scale our culture into a freakin’ Unicorn. Quantifying the 5 dimensions of the Pirate Metrics to check your company’s cultural pulse.

**Acquisition**

Here’s the deal: Startups don’t work without customers, they most definitely don’t scale without customers and they will never be profitable without… you got it, customers!

So we all put a lot of effort and money into acquisition. The same applies to your culture. Your culture’s customers are the PEOPLE that you hire. If you want to acquire these customers, you need to:Demonstrate your culture and your company’s value

Make them want to come to you, by clearly showing that you’re solving a pain they relate to and you’ll make someone’s life better

Allow your prospects to know more about you, to explore and learn about what you’d do for them in detail

Have a Recruitment team and process that is better than your Sales team (because they will also have to recruit Sales people)

Do things that don’t scale if you have to. Like with your product, you want to do things smartly, not mechanically. Maximise your efforts for learning. The first people coming in through your door: they’re the ones that will make you succeed.

**Activation**

Awesome, your first customer is through the door. Regardless of whether you’re a consultancy company, a design firm, a coffee shop or an internet economy giant, you want to delight them, awe them, drive them to their magic moment.

Then, you promise to repeat that experience for EVERY customer walking in.

So isn’t that what you need to do with your people as well?

It’s not enough to point people to their desk, giving them the latest ultra lightweight macbook pro and two 4K screens and let them do their thing.You come to their desk the next day, ask them your best version of:

“How’s it going, pal?”, followed by a quick “Oops, gotta run for a meeting with a big fish now. Catch’ya later! Let’s make some money, shall we?”.

I know you wouldn’t do this, but that’s what it sounds like to them when you’re not worried about onboarding your people the best you can.

Make their first experience extraordinary.You should be empowering them, showing them why you founded this thing in the first place, who the people are and what they’ve helped build, and where you’d want to have it in 1,2,5 and 10 years.

If their first contact with your product is special, they’ll be activated, they’ll find their magic moment, they’ll feel like your mission is their mission.

Make that moment count.

**Retention**

“What retention?” you might ask. “You want better retention than paying them good money every month?”.

Ok, first of all, yes. Money isn’t everything.

Secondly, retention is as much about having people invested as it is about rewarding them.

Picture this:

I’m on the internet. I am the customer.

A while back I found this great shopping site that let’s me find great deals on electronics. I’ve bought with them before and it went well. I’ve had to send my smartphone back once, they weren’t very helpful with the instructions and I ended up having to pay for postage because the whole thing wasn’t clear. Another time, I had a question about an order and they didn’t come back to me until after I insisted a week later. Still, they ARE the cheapest out there, so I can put up with these annoyances. As a company, they’re doing great and have been around for a while.

Now, a friend of mine tells me about Amazon. I’ve been looking for new headphones lately. I dive in, find the same model I’ve been looking for. They’re not cheaper there than on that other site… But I start thinking about the last pair of headphones I had. They broke after 6 months and I had to threaten to sue before they admitted it wasn’t my fault and sent me a replacement. Is Amazon’s customer service any good? I call my friend — He raves about it. It’s great! Best thing he’s ever experienced in his life!

Oh well, let’s give it a go! There are NO barriers to exit from my current product, and there are almost no barriers to entry in this new one.If you’re a company and deal with highly qualified and talented people, you are in this same situation. They’d find a job in 2 weeks if they wanted to, and the fact that you’re a good deal NOW, does not mean the same will be true in 6 months.Work on retaining them. Raise barriers to exit. Make them know you care, they’re appreciated, their work means something and you wouldn’t make it without them. Give and ask for feedback. Be responsive and have a great User Experience. If they have any problems, provide AWESOME customer service.

When the going gets tough for you, they’ll stick around.

**Revenue**

You’re struggling to make ends meet. You’re a startup… You’ve just barely started paying your own salary and this is you: working 18h/day, dreaming/having terrible nightmares about it the other 6h.And here I am, talking about how you need to build a culture that will make you thrive? You need to fix bugs, launch features, get shit done! Well, culture is getting-shit-done. In fact, if you do it right, you’ll get more shit done than ever before. Most importantly, the right shit. The shit that matters because your smart people are engaged and want to find out what that is.Your people will be more talented, deliver faster and more reliably, you’ll spend less time in pointless meetings and explaining things they should’ve known from day 1, having discussions about who owns or was supposed to do what.

Revenue won’t be born from culture, but it will only grow as fast as your culture allows.

**Referral**

The power of your product is exponentiated by great PR. Word-of-mouth is the best acquisition channel you have and social referral is the new word-of-mouth. To go Viral, you want every customer to refer more than one other customer. If you do your job right, your best customers will often know other great customers they will refer to your product.

Extremely talented people, will also know other talented people. They most likely didn’t get there alone, and they have recognized themselves in other many times before. They will know someone else who can add to your company and they will be your best recruiters. Promote referrals, encourage them, have your people vouch for your new people.Leave room for others, of course, you don’t want to fall into the trap of making everyone look alike. Diversity is important, and it’s not because of political correctness. It’s because it prevents you from tripping over your own biases.Treat your people like you treat your product. Measure how you’re doing in Acquisition, Activation, Retention, Revenue and Referrals. 

Set up a system to do this. 
Your world-class culture will take care of itself.

Originally published Jan 22, 2018

When we talk about organisational models and systems of incentives as applied to companies, the conversation often (as with other topics) falls into dualism - implementation are wrongly pictured as just black or just white, nuance is removed from the conversation and the pitfalls of applying an incentive structure and goal-setting framework to an organisation are a second class citizen.

By system of incentive, I generally mean an organisational framework that allows departments and teams to define and pursue a given strategy, set goals, monitor their progress and celebrate their achievements. These frameworks end up defining which behaviours get rewarded, who progresses in their careers, which teams and individuals are considered high-performers, what metrics are in the company’s dashboards and what colours they’re displayed in.Geckoboard’s Mixpanel example integration with key web metricsIt is clear that these shouldn’t be taken lightly. Every rational individual within a given company will steer their behaviours towards what is rewarded, so these frameworks end up playing a fundamental role in defining the emergent and fractal set of behaviours we call culture. When executives try to create cultural shifts by architecting these incentive systems, they need to simplify the mental model of their organisation to a set of characteristics that need to be optimised. For example, one might be trying to increase throughput and decrease bureaucratic overhead, noble goals, so they deploy a system or framework to incentivise teams and employees to do so.

This post looks at how culture plays such a big role in the effectiveness of the models and framework of choice, and how when heavily optimising for some easily legible traits, you might fail to introduce checks and balances to counterweigh their negative consequences and other n-th order effects.

## Let’s talk about OKRs

OKRs are an evolution of Management By Objectives and were initially used at Intel during Andy Grove’s tenure and have since skyrocketed in popularity after Google popularised them. They are one of the most commonly used goal-setting and tracking frameworks. On the surface, OKRs seem fairly agnostic: You have an organisational goal, so you write an objective that reflects it. Then you link it to a series of Key Results (you think would mean you were successful in attaining your objective.OKRs allow departments and teams in large organisations to align their local objectives to the executive and strategic goals , they provide a means for teams to feed back into what their Tribe / Cluster / Department’s goals should be, and they’re supposed to be stretch targets — i.e. achieving 60–70% of your goal should be considered a success.

So it looks like a pretty good deal — and very often, it is. 

It provides a framework for alignment at scale, they rally people behind a measurable key result rather then the Product Manager or Department Head’s pet project, they give you clarity and focus and they are ambitiously set to force teams to go the extra mile in achieving their goals.

Now, Google themselves have recognised some of the pitfalls of deploying this approach at scale. There are some easy traps Google found are easy fall into and orgs should do their best to avoid them. 

For example:
**1. Miscommunicating stretch goal OKRs** — misunderstanding and misalignment between teams about how ambitious their OKRs are. If dependencies exist between teams, they’ll often be committing internally to a different threshold of success. Say for example Team A expects Team B to deliver Impact X on Metric Y. Only if Team B delivers on Metric Y, would Team A’s KR that looks at moving Metric Z be accomplished. This can lead to frustration and lots of fingers pointed at other teams.
**2. Business-as-usual OKRs** — Team-centric OKRs (as opposed to customer-centric) are also a fan favourite. They are chosen by the team to guarantee they keep working on their favourite project and they don’t necessarily move the needle on the company’s strategy. A common counter-tactic is to stack rank all OKRs and guarantee people are always allocated to higher impact OKRs.
**3. Sandbagging** — is, again, to guarantee team’s goals look like stretch targets but aren’t necessarily so. The team knows they’ll get there if they stay course and they might even have time and energy left for that one great project they wanted to do anyway.
**4. Low-value objectives** — the name says it. They might be hard to get to, they might keep you busy, but they’re not really worth the effort and they won’t produce impact at the company level. Again, stack ranking might help keep people focused and incentivised to do right by their customers.
**5. Insufficient key results for objectives** — Google’s final piece of advice is to ensure objectives are appropriately funded by their associated key results. It is easy to set stretch objectives but then only commit to hyperrealistic results (i.e. Business As Usual KRs). Achieving your KRs needs to mean your objective has been fulfilled.Apart from team-level pitfalls with OKRs, there are a few organisational ones that are easy to stumble on and are worth noting:
**6. OKR blindness** — Now uou’ve set your goals, have a measurable way of tracking their achievement and you’re on your way. Depending on how your company is structured, though, this can easily degenerate into a culture of self-interest and lack of peripheral vision. It doesn’t suddenly make good people turn bad. It can, however, provide the wrong incentive, causing people to forget about the complexity of the business, its changing needs, and oversimplify complex market needs to assume that the team’s only job is to deliver on theirs. Say, in this case, Marketing team A needs your team’s assistance to unblock a major promotional campaign that is likely to increase sales by 20%. Team A doesn’t have any engineering resource, and it would take a developer-day away from your sprint. If none of your OKRs matches that need and you’re tight on time, your incentive structure could mean they get rejected, even if you are the right team for what was, in the grand scheme of things, the right job. In medium/large organisations, which are always subjected to a form of unit/functional/matrix slicing, dependencies are very natural (even between technical teams) and solving them requires empathy, cooperation and a world-class prioritisation toolkit.
**7. Incrementalism** — Another trap to look out for with OKRs is a strong bias towards small iteration and incrementalism. Because the initial target is quite arbitrary, there is a tendency for continued motion, path dependency and continuity. If a team has set a stretch goal and has spent 3 months toiling away to achieve it, it’s very unnatural to then diverge in their next OKR planning session (which often happens a mere 1.5 months after their current cycle has begun) and set a completely new goal because of a new piece of information. The easiest thing to do is to keep trying to solve the problems you’re good at, iterating and incrementing your product, with little regard to how it fits the company’s current state and its market.
**8. Local optima** — Inflection points are hard to detect, more so with a framework that is poised to be ambitious, sets SMART goals and offers a clear and legible explanation of the company’s strategy. It is extremely difficult to detect that you might be stuck in local optima while in the midst of the struggle, deep in the build trap. The ability to learn at scale is one of the most important characteristics of fast-paced, high-growth organisations. Creating a structure that allows companies to reinvent themselves is hard and how Apple and Amazon chose to do so is extraordinarily different (Depth vs Breadth). It’s important to give teams the skills to learn as fast as they can, and the freedom to expand and move away from their OKRs if they discover they’re solving the wrong problem, otherwise your perfectly crafted Key Results can be the fastest route to a permanent state of Innovator’s Dilemma.
**9. Fragmentation** - which is extremely hard to counter as companies grow, is the results of the natural tendency for hyper-specialisation and the entropy and friction that arises from multiple teams trying to solve problems that are too specific. OKRs can make this worse if left unchecked. Teams will disregard others’ goals, build their own solutions to already solved problems, all to reach their quarterly targets. It can lead you down a dangerous road of divergence without alignment, creating force vectors that prevent the business moving forward, rather than propelling it with greater strength in the direction of focus.
**10. Premature convergence** — Because people are often painfully aware of the pitfalls outlined thus far, OKR exercises can be hard, take away large chunks of every middle manager’s time and end up compromising on least common denominator goals due to time pressures, dependency bottlenecks, budget constraints, legacy tech, top-down directives or lack of team buy-in. These and other factors can aggravate the fact that OKRs objectivity and focus can actually be detrimental if you’re solving the wrong problem. We need to stop and consider they might actually be too specific (hint: if they map one-to-one with a task, they are) and it would be empowering to teams in many organisations to receive high-level direction with a framework for accountability, without implicitly prescribing the tactics to success via proxy metrics.

Teams in regular 3-month cycles may soon discover they’re not able to have the impact they were supposed to, but not have the contingency to change plans as that would mean diverting from a largely arbitrary target. They also often fall into the sunk cost fallacy, and remain convinced that they’re solving the right problem because that’s what they committed to 3 months ago.

## What these problems say about OKRs (and other incentive frameworks)


Some obvious patterns emerge when looking at what these pitfalls signal about large scale organisations. One is companies are complex, living organisms and applying a blanket system of incentives (whatever it may be) will oversimplify the network of interactions and behaviours across teams building product. Any framework we choose needs to have strong guardrails and counterweights to account for possible traps, as well as have contingency plans built into them that incentivise teams to stay smart, keep optimising, stay focused, share widely and collaborate to discover what the right problem to solve is.

In the case of OKRs, organisations soon discover that:

a) it is unnatural for people to set unachievable goals
b) that dependencies are often poorly reflected in them
c) that teams can take advantage of the model to signal success
d) that a disconnection between biz goals and KRs, as well as between KRs and objectives often emerge
e) that highly-specific short-term goals can hinder creative behaviour and long-term thinking
f) that solving for incremental optimisation at a local level doesn’t always equate to global growth
g) that fragmented, team-level (or functional) goals can dissolve how much value customers end up receiving.

## What will your organisation amplify

This post focuses on OKRs because that’s what most companies have chosen to use over the last 10 years after Google popularised them. The principles of framework-organisation-fit, though, apply to every model in every organisation. Organisations should plot their models, their cultural traits and their ambitions, against the benefits and the pitfalls of their goal-setting framework.

They should also be aware of the fact that while they may be looking at both the model and their org in a mostly unidimensional manner (pros and cons, good and bad), the end result is a complex matrix. Think of it like multiplying an Nx1 matrix by a 1xM.

 ![1_XoGXBgvHilNBOIIADicdTg.webp](https://writing.colivetree.com/u/1_xogxbgvhilnboiiadicdtg-4Jq1O8.webp) 
> The resulting matrix is a lot more complicated than its originators.

The end result is an NxM matrix, a complex reflection of how each individual trait of your model influenced every single aspect of your company’s genotype. You should be aware that, unlike on paper, what this matrix ends up looking like is very often extremely unpredictable as there are dependent variables all over the place and hidden layers your model of reality won’t be able to reflect. Likely there will be nth-order effects that will need to be managed. This is fine. Test & Learn, iterate quickly, do your OODA loop as fast as you can once you acquire a better understanding of what the end result actually should be.

Remember that the end result may or may not be net positive for your organisation, so hard leadership decisions will have to be made — has this change provoked the positive effects we expected? Have we managed to contain and turn any negatives into strengths? Are you now better prepared to respond to the challenges you started with?

## How to predict the future

So far we’ve looked in detail at how you can create positive change by modifying the incentive structure in your organisation. How OKRs can be that driver but need orgs to either already have or be ready to develop a set of cultural traits that make them succeed. How a seemingly linear multiplication can result in a complex behavioural matrix that can be net-positive or negative depending on your goals, your culture and the maturity of your organisation.

A few tips from the battlefield on how to predict the future and make sure that you maximise your chances of success with OKRs or another strategic objective framework.

### 1. Don’t push large-scale changes from a single functional lens

Get buy-in. At the exec level. Use it to get buy-in across the whole org. This will not work if Product people set OKRs that no-one cares about. It will also not work if Engineering set OKRs to work on large projects with no view of the impact to the customer. It will not work if you “forget” to tie it to your strategic goals.

Everyone involved needs a deep understanding of why you’re changing the game and they need to be completely involved from the start.

Say you choose a similar structure to Spotify’s Rhythm and the DIBBs framework. It won’t accrue to much if Data used isn’t available, reference-able and prioritizable, visibly linked to the company’s needs and directly connected to its most important goals, if the Insights you’re extracting aren’t understandable and can’t be challenged by teams on the ground, if resulting Beliefs aren’t widely shared, culturally and contextually relevant, and if teams don’t clearly understand the Bets they’re going to make and why.

They need to know the problem they’re solving, how they know it’s a real problem and how they will know if they’re making progress towards achieving it.

## 2. Map your organisation and reintegrate it to deliver on goals

If you’re organisation is structured in tightly knit, sometimes competing units and they are given mismatched objectives, they will more likely than not aggravate the natural friction — there is natural tension between a unit focused on increasing the Average Order Value through cross-sell, and a Conversion Rate Optimisation unit, who are both given aggressive growth targets.

Your organisation needs tools to solve these problems autonomously, instead of falling back on analysis paralysis, constant escalation and turf wars. So whatever incentive framework you lay out, ensure that:

1. people that need to work together are highly aligned, that they clearly understand the goals and the focus
2. relative priorities are clear (stack rank if you must)
3. small enough groups of people are empowered to autonomously deliver relevant outcomes without having to untie a web of dependencies
4. operating principles allow teams to invalidate assumptions and quickly change tactics
5. that multidisciplinary voices are participating actively in your delivery pipeline
6. ownership of the end product is not so diluted that no one person really feels they’ve accomplished something.

### 3.  Build guardrails and safeguards

With any structure, there will be need to be a clear problem description, a clear rationale to support it, and a sound way of monitoring progress: quantitively, qualitatively or, ideally, both.

If you’re deploying OKRs, take another look at the section on pitfalls and what your organisation will amplify. If there are obvious traps, design your initial plan so that they’re covered. Don’t dismiss them, deploying a new structure is hard so, design like you’re right and test like you’re wrong. Over-communicate. Don’t fail because of the known knowns.

### 4. Treat it as an experiment

John Boyd’s OODA Loops, assimilated into the industry as build-measure-learn cycles, are categorised as asymmetric fast transients, the ability to change states extremely fast based on new information that invalidates previous beliefs. Whatever the model is, be sure to test small, scale it fast and iterate incrementally.

Feedback loops will be more valuable if they’re bottom-up, people need ways to provide structured feedback that allow you to action new experiment iterations at scale. Change never happens overnight, your new framework will need time to succeed, but it is no less important to keep an eye out for the unintended consequences, the impact it is having on your system, and any tribal behaviour or identity politics that have emerged as a consequence of a new found incentive structure.

If culture eats strategy for breakfast, as Peter Drucker famously said, be sure to give yours the breakfast of champions.

Let's look at one of the primary indicators companies use to increase their Average Revenue Per User, build audiences, increase orders and which has a whole field of optimization dedicated to it: Conversion Rate (CR).

**Talking about Conversion Rate**

The basic formula is dead simple:

> Conversion Rate = Completions / Users

So if you run a commerce operation and your ultimate completion is an order, say you had 1000 users and those users made 10 orders, your conversion rate is 1%. Easy, right?

I agree. It’s easy to monitor, easy to compare, but over time, and as you grow, looking at all your users and comparing them to all your orders, becomes unhelpful when it comes to making product decisions.

**Breaking it down**

The most common and useful way to break Conversion Rate down is to use time. Say you’re looking at users who convert within the first day we’ve seen. them on the website. We’re now analyzing something like:

> Conversion Rate (1d) = Completions (1d) / Users (1d)

But… sessions

If you’ve ever used Google Analytics(GA), for example, you’re now wondering how this is comparable to their definition. In GA, conversion rate is calculated using completions and sessions.

> Conversion Rate (GA) = Completions / Sessions

A session in GA is a variable time interval, that begins when the user first arrives at the site and expires 30mins after their last interaction. One obvious consequence is that one user can have multiple sessions.

The point of the session definition is to try to capture one of your user’s visits to a website until they’ve left. If within 1000 sessions, there have been 10 orders, your conversion rate is 1%.

For the standard definition, GA doesn’t actually care if those sessions came from 1 or 1000 users. If your whole 10-member family is rooting for you and visiting your website 10 times a day for 10 days, that actually can account for your 1000 sessions. If your mom bought one article a day to boost morale, that could account for your 10 orders. Google only cares whether those visits (or sessions) turned into a purchase or not.

It does tell you how many users were behind your session count and allows you to change your definition, so it’s worth keeping an eye on both.

That definition, however, as you probably captured by now, changes everything. If you look at your 10-day conversion rate, it would vary between:

> CR = 100% (10 orders / 10 users)

> CR = 1% (10 orders / 1000 sessions)

Which, if you’re wanting to make actionable decisions, might actually change everything.

Wait, there’s more. The question you were probably trying to ask by looking at your 10-day conversion rate before you started drilling down, was “how many users have ordered something from me?”

That’s really 10%, right? All the orders came from our mom, and only 10 family members can actually account for all the visits!

> CR = SUM(Unique Orders / User)

And that’s before we start worrying about double-counting users (if they’ve visited on different devices, for example, and we can’t figure out that that’s actually the same person).

**So what SHOULD we care about?**

What you want out of whatever way to measure CR you choose is that it is actionable, that it gives you a way to measure progress through time and make useful comparisons between groups.

So let’s look at how differences in looking at the metric can affect the decisions you make with it.

Imagine applying different timeframes will make your conversion graph plot something like the below:

 ![1_6aNye3RMcGVb7A1X03Lk6Q@2x.webp](https://writing.colivetree.com/u/1_6anye3rmcgvb7a1x03lk6q-2x-sczMD4.webp) 
> CR over longer and longer timespans for the same user groups

With a chart like the above, it may be relatively easy for you to identify a website/app change that affects your 30-min CR (a 10% improvement in session CR would take you from 5% to 5.5%).

That might barely if at all register on your 7-day or 30-day CR, since these improvements might be either negatively offset over that period, or just be small enough as to not even show on that long enough timescale and user base.

Sometimes, you might even see the opposite effect, with that specific change decelerating the CR progression curve and causing it to stall sooner since there was an unforeseen (negative) effect downstream.

Here are a couple of examples.

**Example 1:**

Session-1 (30min) CR increases by 10%

This happened because you’re offering a 30% coupon for users who buy on their first visit, which led to a 

decrease in Session-2+ purchases

Which happened because word got around about the campaign and new users flooded your site with instinct purchases, which then led to

30-day CR going down

Which in turn was because many of those customers who didn’t end up buying in their first session actually returned less than your typical new customer to the website. To add to that, your returning customers actually felt disappointed they were excluded from the promotional cohort and ended up purchasing less.

In this scenario, to measure the net success of the campaign, you’d need to compare and contrast behavior across both cohorts (new vs returning) and understand whether the end result was a net positive.

**Example 2:**

7d CR up

You’ve launched an aggressive basket abandonment campaign that targets users 3 days after they’ve left the website with something in their basket. This leads to some of those customers coming back and purchasing on their 3rd day, increasing conversion rates on the 7-day timespan, but led to

fewer returning visitors in weeks 2–4

What you’ve noticed is that there is now a reduction in visitors coming into the website on weeks 2–4. A lot of people were annoyed by your insistent email and have either unsubscribed or just not visited the website at all, let alone your basket page. This led to

30d CR going down

As the conversion rate improvement through your email clickthrough cohort was completely offset by those who visited less and unsubscribed from your communications.

There are multiple causal reasons for phenomena such as the one described here (and others) to occur, so it’s important to not take the numbers at face value and dig deeper into users’ behavior to understand what behaviors we have introduced through this change, as well as what we were trying to incentivize.

It is also important to have an evaluation criterion that reflects not just what could happen through a positive result, but also what types of scenarios could occur if the experiment went wrong (and choosing monitoring metrics that account for that).

**Heuristics for decision-making**

Your brain will be primed to start thinking about this as you develop a sense for the types of results experiments may produce, but there are a few questions/heuristics that might come in handy as precautionary measures when trying to move the needle on CR, though:

1. Is CR the ultimate metric we want to affect? (i.e. is this a funnel efficiency problem)

2. What secondary metrics can we measure that would let us assess the trade-offs of our decision? (7-day retention, % order returns/complaints per order, visit frequency, % users with a 2nd order)

3. What is our typical purchase window and how do we capture the behavior we’re looking to effect? (e.g. do our target users shop once a week or more, do they browse a lot before purchasing and only purchase a couple of times a year, is there a bimodal distribution where some purchase on a whim and others take a long time to decide? — this might change our key metric time window as well as our secondaries/monitoring)

 ![1_YUFskPQSFGjmwmkL1-4w-w.webp](https://writing.colivetree.com/u/1_yufskpqsfgjmwmkl1-4w-w-yLkXrU.webp)  ![1_aeh2WviQJWxjf7R-athADg.webp](https://writing.colivetree.com/u/1_aeh2wviqjwxjf7r-athadg-8FvwuN.webp) 

> Two distinct conversion behaviors. One where customers typically complete their task within the first three days of initiating their shopping, with a long tail of longer-horizon purchases (7 and 30d), and a second where purchases either happen on a whim (within their first session or their first day of shopping) or wait a long time to make their purchase decisions (7d). Selecting different conversion indicators as your key metric could yield significantly different results for your optimization efforts.

**Almost done: Don’t forget to define what a user is**

Finally, this may look like a no-brainer, non-issue, but more often than not, it is not. How are you tracking your user count?

If it’s a web app, do you keep an ID that’s set on the user’s cookies on their first visit? Are you double counting mobile web and desktop users?

If you do, when do they expire? How and when are they set?

Do you use that ID to allocate them to your experiments?

When the user logs in and you can identify them, do you reconcile and backfill your data or is there a chance you’re double-counting in places?

This may sound basic but there are loads of confusion around what a user is, how to handle corner cases, and how that affects test samples and experimental groups. Knowing and understanding how it affects your comparisons and your analysis is key to making good decisions and optimizing your conversion rate.

## How to move the LTV needle

 ![1_Faro5cY8XKvYL0AiQcq6ww.webp](https://writing.colivetree.com/u/1_faro5cy8xkvyl0aiqcq6ww-EIME2n.webp) 

In general, any loyalty scheme is built around two key factors that brands use to incentivize customers in order to drive their Lifetime Value (LTV): one that’s financial, another that’s emotional.

On both accounts, what we’re doing is creating an incentive for our user that generates a net positive effect on Average Revenue Per User (ARPU), within a reasonable payback period given the SAC/CAC we incurred in (Subscriber Acquisition Cost/Customer Acquisition Cost), our Running Costs (and runway) and our Cost of Capital (WACC).

Usually, that is done by offering the customer a discounted offer on their current or proximal purchase / spend (with said discount in the form of price, promotion, convenience — such as shipping costs or upgrade options), which actually negatively impacts someone’s ARPU within a short time frame, while lowering the cost of their preference on a subsequent purchase (reacquisition costs, lowered price sensitivity), thus ending up positively impacting SAC/CAC and ARPU within what is called the payback period, through volume in incremental purchases.

If done effectively, it significantly raises barriers to exit, by virtue of a positive feedback loop that promotes an on-going relationship with the brand, where it becomes first to mind.

If not, the pitfalls of LTV kick-in and companies run out of runway before they make their CAC/LTV equation pay off — uber is a recent famous example where Venture Capital was used to drive growth with a clearly unsustainable CAC/LTV formula, to drive out competitors and establish a dominant market share in key geographies. One key thing to understand about LTV is that it is, by definition, very lagging. Because we’re waiting for a long enough time to come to completion in order to compare different cohorts of customers, we need many micro-moments of interaction with our brand touchpoints to occur, before decisions are made.

In order to measure their effectiveness, we want to look at incrementality. Typically those that are more sensitive to the effects of loyalty programs are already those more intent on purchasing frequently, typically leading to a self-selection effect emerging through the data, particularly when cohorts aren’t too big, making it hard for companies to understand the individual impact of their benefits and incentives.

For larger cohorts, companies can create holdout groups to control for these effects. The operating trade-off here is that you usually want to ensure your most loyal customers are immediately included in the program, getting full access to its benefits, and feeling that they’re valued, which makes things harder for those measuring it, as it may lead to an unreliable comparison with the holdout, which contains none of your most engaged customers. However, hard to measure isn’t impossible, and there is very strong reason to run cohort analysis, split testing whenever possible and even controlled experiments in order to successfully optimize loyalty programs.


## Loyalty driving LTV

Let’s now look at a few well-known examples of brand loyalty incentives, aimed at increasing LTV through incremental ARPU. These include:

### Paid Bundled offerings

An interesting but hard to nail value proposition is a paid-for membership. Customers are required to pay for a subscription themselves (driving ARPU), which they will make up for in accrued value over time (potentially increasing Costs). The most famous is Amazon Prime, where customers pay a flat monthly/yearly fee to get free next-day delivery (which could cost up to $10+ per delivery). Additionally, Amazon has added a series of value-add services to the subscription (such as Video and Music), which incentivizes customers to continue using it for their commodity purchases, as well as to keep paying for continued access to their ancillary products.

### Spend-level offerings

**Tier-based**

Tier-based programs are normally based on customers’ spend with the brand to gamify their relationship, using the promise of further rewards as a way to incentivize their continued relationship with the brand (+ARPU). The more customers have spent, the better (and more expensive for the brand, +Costs) the incentives would be, playing on both the economic function of the rewards, as well as the social status associated with them.

Sephora (+ community) / Farfetch

**Point-based**

Points-based programs tend to use the same spend-based mechanism to reward customers, but they accrue points towards a flexible system within which a monetary function exists, to collect rewards towards their next purchase. This incentivizes customers to spend again within the points’ lifetime. Airlines are famous for rewarding frequent travelers with points, promoting them to not only stay loyal on their frequent business routes, but to also use them for personal travel. The high barrier to entry with points systems, also means that once customers are engaged and understand the point system fully, they become their biggest distribution channels.
* Nordstrom
* Airline Miles

**Nectar points/Coupons & cash rewards based
**

Another type of loyalty scheme consists of rewarding customers directly with either cash back or coupons towards their next purchase. Whereas cashback ensures a customer uses a given card network or affiliate site (which pays customers out of the commission they get for driving the purchase), coupon-based loyalty schemes typically offer coupons towards a customers’ next purchase based on their own / their peers’ buying habits, diversifying customers’ basket of purchases and driving habitual purchasing behavior.
* Cashback schemes
* Branded credit cards
* Retailer loyalty cards

Customers make upfront investments in a brand in order to recoup them, over time, multiplied. Brands lower their margins for these segments in exchange for incrementality, ultimately driving lifetime value. By engaging with the program, there is also the expectation on the part of customers that they will come back, which is not always true — see projection bias — and that there’s a positive trade-off in choosing the seller over a competitor in a subsequent purchase. Rational or not, this guarantees that a larger share of wallet will be spent with the brand than would otherwise be the case.

Demand, once bought in, also tends to be less price elastic and more prone to making emotional decisions, thus more sensitive to coupon marketing, abandoned basket messaging, exclusive campaigns for commoditized / brand goods, sales seasons (particularly when combined with the possibility of creating exclusivity for loyal members).

Having programs such as these allows brands to create influence networks that treat power users as stars, growing their own proprietary distribution channels: If they become aspirational references for the masses, those who retain the greatest value out of these programs (the points addicts, the platinum card customers, the early adopters), then become a company’s greatest advocates, each bringing in many new customers and inspiring tens to thousands of less-than-committed followers. Not all of these will become power users themselves, but by virtue of believing that that is true, they’ll still prefer buying with the brand and chasing ever-fleeting rewards, which lowering acquisition and re-acquisition costs.

Finally, another lens through which to look at driving LTV through increased ARPU is the softer version of loyalty. Companies drive retention and loyalty through excellent levels of Customer Service, frictionless purchase experience (1-tap checkout), emotional attachment, or sunk data costs (such as your friends’ graph, a fully organized photo album or all your phone’s data fully backed up). The issue again is measuring the effectiveness of these practices beyond a principled approach to product and customer service, beyond the elusive but instinctive common sense.

As Jeff Bezos insists, however, “Your margin is my opportunity”, and driving excellent standards of customer experience has never been known to hurt a brand.

Strategy

There is a recurrent thread going on in tech circles that contrasts 1) the philosophical approach of companies that have adopted the lean startup practice of rapid customer development cycles and pivoting with your learnings vs 2) companies that are thesis-driven, have a big mission and are relentless in pursuing it, bending reality to their will — using examples of product visionaries like Jobs, Gates and Musk.

One very recent example (at the time of writing):

 ![Screenshot 2024-08-20 at 14.59.27.png](https://writing.colivetree.com/u/screenshot-2024-08-20-at-14-59-27-m6Z3MN.png) 

The conversation has degraded into a love/hate discussion around companies doing experimentation, as if being rigorous about your hypotheses and attempting to invalidate your riskiest assumptions somehow precludes you from having a vision of the future and how you’ll change it. I’ll try to address some of the confusion around that in another post.

This one, I’ll use to structure how a Product Manager should think about that future, build out his product vision in material terms, turn it into a product strategy and then pursue that strategy with tactical actions that enable the real product shape to emerge from both convictions at a macro scale, and experimentation at a micro-scale.

## What strategy is

Good books and practitioners of product strategy have tried to outline what strategy is and how it translates into actionable practice over the past few years. Thinking about strategy is not new, of course, but its application to the internet economy and digital products has really been defined more clearly over the past 10 years, and books such as Good Strategy / Bad Strategy and, in particular, 7 Powers — recommended by some of the best founders and investors in the industry - have helped mold this collective knowledge base through amazing synthesis.

Others, like Ben Thompson, Tren Griffin, Web Smith, Gibson Biddle or Ryan Singer, write, teach and distill product strategy through their writing, analogies and analysis. Let’s define strategy through some of their insights:

> “Good strategy works by focusing energy and resources on one, or a very few, pivotal objectives whose accomplishment will lead to a cascade of favorable outcomes” — Good Strategy / Bad Strategy

> “How will your product delight customers, in hard to copy, margin-enhancing ways?” — Gibson Biddle

> “Power: The set of conditions creating the potential for persistent differential returns. Strategy: a route to continuing Power in significant markets.” — 7 Powers

The ideas of strategy and power are directly linked to the fact that, once you’ve achieved it, you’ve established a competitive advantage that can be defined by both the economic benefit that it accrues to your company, as well as the barriers that it imposes on competitors and new entrants.

In other words, it creates a **moat**. Moats are usually applied to product companies when they’ve established sufficient differentiation that it appears insurmountable for a competitor to cross the gap competitively, given the current market landscape. Google’s dominance in search is one such example of a moat (everywhere but China and Russia). Anyone trying to make a dent on web searches would have to go head-on with G’s technological dominance, brand power, distribution advantages (such as the 9B$ premium it pays for being the default search engine on iOS). For any competitor to disrupt Google in this space, a significant market transformation would have to occur (one such as the explosion of decentralized internet content that led us to the need for Google in the first place).

It’s important to note that Google turned into Alphabet, which is a dominant conglomerate of internet companies, and has probably overgrown its original mission to “organise the world’s information and make it universally accessible and useful”.

Their vision gave way to new visions, and their strategy has evolved alongside them. It has emerged from their thesis, through a culture of experimentation at a massive scale. So while it is clear that the company has changed drastically throughout its lifetime, it is also relatively obvious, in hindsight, that a similarly large and world-changing company would be unlikely to originate from a different strategy.

## Thesis-driven vs emergent — a false dichotomy

So before we move on to the 7 powers lenses on Strategy and Power, and how they can be applied to your product development, a picture is starting to be formed as to how working out your strategy and developing a thesis for how the world (or your company) will be different when you fulfill your larger, more ambitious goals, does not change the fact that you’ll pack a lot of assumptions into your problem, solution and execution spaces, that you can invalidate through rapid and rigorous experimentation at a local level. The outcomes of your experiments — which are ways to de-risk your tactical bets and measure the compatibility of your views and the market’s — , coupled with your conviction and relentless pursuit of your thesis, will drive your company forward.

 ![1__9GbKrZ0hEXc0T-8wRVgnA.webp](https://writing.colivetree.com/u/1__9gbkrz0hexc0t-8wrvgna-F1GFoS.webp) 

### (Side notes on emergence)

On the importance of uncertainty and emergence, Alex Danco notes, in his Two Truths and a Take newsletter:

> First, there’s the problem of emergence. If you start from biology, it’s pretty easy to work your way backwards by reducing biology into its component parts — you’ll find chemistry and physics as its underlying components, with nothing unaccounted for. But it’s hard to go the other way. Life is a complicated, adaptive, messy thing. If you start with physics and chemistry, it’s hard to identify what exactly is the thing in here that gives rise to life. We say that life is an “emergent” phenomenon, which lets us dodge the question of “emerges through what, exactly?”

This speaks to the relative ease of working from an ex-post consummation of strategy and boiling it down to its essential tactics and experiments, but also to how hard it is to predict that exact set of steps, and what they would lead us to achieve, had we not have run those experiments (including the many that failed). The largest players in the industry report 10–30% rates of success in their experiments, which, arguably, could be even worse / more catastrophic if they weren’t able to measure them.

### Writing it down

Good Strategy / Bad Strategy identifies one key tenet of great strategy has the fact that it must begin by 1) clearly identifying the current obstacle in the way to obtaining strategic power, 2) set out a guiding policy (the guardrails and overall direction of your strategy) and 3) establishing a set of coherent actions, which together, will allow us to overcome the obstacle.

This exercise is very often missing at the highest levels of Product leadership. Product people, when they can think of a better version of the world, also may think of a series of tactics (typically designed to fit in a slide deck) that can be used to kickstart the product engine, but there’s usually lack of good directional policy — one that allows individuals to make informed trade-offs — and even of coherent and reinforcing actions, which, being successful would compound to let us overcome the obstacles on our way to market power.

Amazon’s product function (in effect guided by their executive shaman’s communication style — see his ’97 shareholder letter), seems to have recognized both the human inability to clearly visualize and describe the changes we want to produce in the future world once our product succeeds, but also how we fail to outline and critically analyze our guardrails and tactical actions in both timely and effective manners.

This has translated to the way the company does product briefs, through their use of 6-pagers as product briefs and the use of the Working Backwards methodology. This gives PMs and Execs the latitude to explain the product in detail and examine its key assumptions and risks, outlining a plan to execute against them. What key hypotheses they have, how they coordinate and compound, how they address the obstacles in their way, and how they’ll eventually lead to a moat.

The purpose of these documents is to lay out your product thesis, with a market and customer-centric voice, and then backtrack all the way to how they’ll play out in policy and tactics in order to make you win.

This means crystallizing your vision of the future in such a way that it is actionable, but that leaves enough latitude for regular failure, of a non-catastrophic nature, while in pursuit of that vision. That is good product definition. (For more examples of good product definition, definitely check out Basecamp’s Shape Up and Ryan Singer’s attempt to synthesize product shaping).

## 7 Powers

 ![0_stQOiX9-0YoEo-Oh.webp](https://writing.colivetree.com/u/0_stqoix9-0yoeo-oh-8RhUpm.webp) 

Now we have looked at what strategy is and the false contradiction between planning for strategy and letting your product emerge through rapid experimentation and fast feedback loops, which often combine and compound in unforeseen ways. We talked at how writing it down can help you clarify your future thinking and crystallize your product definition and the strategy that underlies it.

We’ll now look at strategic power. What types of moats and differentiating factors your strategy will help you create so that you can design your plans in light of what you really want your business to achieve.

We’ll look at it through the highly recommended classic 7 Powers, which synthesizes the key types of strategic power one can aim to achieve and what benefits and barriers each of the powers carries with it. Some of them are quite well-known and well-studied, like network effects — typical of N-sided marketplaces, or social networks - while others might take a more in-depth analysis to get used to.

### The 7 Powers

**Scale Economies**

Ben Thompson writes about some of the transformational effects of the internet in terms of creating new moats and the impacts this has had on scale economies. In his post “Defining Aggregators”, Ben describes this internet-powered scenario:


“Companies traditionally have had to incur (up to) three types of marginal costs when it comes to serving users/customers directly.

1. The cost of goods sold (COGS), that is, the cost of producing an item or providing a service
2. Distribution costs, that is the cost of getting an item to the customer (usually via retail) or facilitating the provision of a service (usually via real estate)
3. Transaction costs, that is the cost of executing a transaction for a good or service, providing customer service, etc.

Aggregators incur none of these costs:

1. The goods “sold” by an aggregator are digital and thus have zero marginal costs (they may, of course, have significant fixed costs)
2. These digital goods are delivered via the Internet, which results in zero distribution costs
3. Transactions are handled automatically through automatic account management, credit cards payments, etc..”

 
The key insight here in terms of marginal costs is that digital goods have none (or trend towards zero). Effectively, once you create a piece of software, you can onboard new users indefinitely or replicate its instances with virtually zero marginal cost. This means your initial Capital Expenditure (CAPEX), can be paid off multiple times at no additional cost, provided you have efficient distribution and operation. Facebook can now add any new user or advertiser at near-zero additional cost. The same goes for AWS, which has already rented or built out server space and management capabilities, and can now onboard any new paying user at virtually zero cost.This exacerbates something that already happened in the physical world. Often when producing a new physical good, brands and producers incurred in significant costs to produce a limited amount of units ahead of proving their model could scale, before ramping up production and capturing efficiencies in operations, cost of goods, human resources and others, that would allow them to drive down unit costs and capture a larger share of revenue.

 ![1_a622YduPfo9cqzhnRKXiZg.webp](https://writing.colivetree.com/u/1_a622ydupfo9cqzhnrkxizg-K6UhUj.webp) 


This insight from Moiz Ali, founder of Natural Deodorant brand Native speaks to the application of scale economies to physical products and how the initial price point he chose (designed to break-even), eventually led to profitability as production increased:

> “Yes. The cost fell dramatically. We found a new manufacturer when we started scaling. We went from 500 units a week to 500 units a day. And the cost fell in half. Then we went from 500 units a day to 1,000 units a day, and then we went from a 1,000 units a day to like 10,000 units a day. And then sooner or later we were at tens of thousands of units a day. And at each stage our cost fell.”

The same types of scale economies allow Netflix and Spotify to invest in premium content, produce their own shows (podcasts in Spotify’s case, so as not to come into conflict with record labels, who still hold power over distribution in the music industry) and distribute the costs of their purchases over a much larger user base than their competitors (say the cost of a $2B series Netflix invests in would be paid by ~200M subscribers, meaning they’d pay it back within a month, give or take — now imagine that for a competitor or an upstart), earning return on their investments much sooner, allowing them to reinvest and creating a virtuous feedback loop for their shareholders. Which is exactly the type of dynamics that allow Netflix to gain and retain market power.

**Network Economies**

Another one of the most well-known strategic powers is the creation of network economies. You’ll recognize them from marketplace-type businesses or social networks, where there are deep connections between players in the network, and where each additional node (user/customer/supplier), increases the value of the network positively non-linearly.

The power of a network economy dynamic is often compared to that of a flywheel, which stores rotational energy very effectively past a certain amount of energy being invested into the system. This means that once you hit a critical mass point, where the right amount of users are onboarded into the system, it takes you a lot less energy to add additional ones, whereas it would take your competitors (benefitting from smaller effects, a lot more energy to attain and preserve the same energy).

 ![1_hTCgy_BFZ1dke3-vXOMJzA.webp](https://writing.colivetree.com/u/1_htcgy_bfz1dke3-vxomjza-8VHvxE.webp) 

This, again, releases capital that you can reinvest in aggregating demand, in capturing supply revenue, in improving your distribution channels, in improving your search and matchmaking capabilities, or invest in tangent capabilities that strenghten your moat (see Amazon’s foray into logistics and fulfillment as a platform, past their success as a traditional marketplace with low amounts of inventory). For more on network effects, I recommend these 2 posts by A16Z as starters: All about network effects and The Dynamics of Network Effects.

It follows, then, that the key issue in obtaining network effects, is that products seeking them need to be able to power the network with sufficient energy so as to get the flywheel spinning fast enough that it becomes sustainable and creates a moat. Aggregating demand appears to be the way to do it both for social networks (which more often than not begin with no plans as to how they’ll monetize, and instead focus on building the network itself), as well as for modern marketplace businesses, which often focus on distribution-first, a niche market (so as to constrain the amount of differentiated supply they need), or a commoditized-supply regional business (such as scooter-rental), which they can then use to power network effects across other segments.

Even in crypto-currencies, ICOs and other token-offering mechanisms which benefit early-adopters, were ways their network designers looked to solve the chicken-egg problem through a financial reward. In participation the network as a node early on, you’d own a larger share of it, thus incentivizing the creation of critical mass. Unfortunately for them, most forgot that in order to maintain the flywheel spinning, it still needs a level of energy / utility for participants to want to come back. That, takes real power.

**Switching Costs**

Switching costs often pop up in B2B due to how tighly integrated with business practices certain acquisitions are (whether of products or of services). Imagine your company moves into Workday for HR Management and Planning. Not only will all your employees move into the tool, you’ll have had it integrated with your Single-Sign-On server, your ERP, your benefits solution, your expenses management solution, your HR people will have been trained to use it, your employees will have had their data migrated to it, etc.

Even if you haven’t paid a penny of your actual subscription to Workday yet, you’re already incurring in switching costs. Both the financial, the time and the workflow-driven investments you make in the tool (you might adjust certain processes or customize the tool to fit yours), will constitute switching costs when a competitor solution comes along and tries to replace it within your enterprise.

 ![1_ByL5miMST0DyCju215GFmA.webp](https://writing.colivetree.com/u/1_byl5mimst0dycju215gfma-FCpXPc.webp) 

Typically the stiffer your processes are, the more difficult for you to change things up later. Also the larger the amount (of time and money) you invest organizationally into a solution, the larger the sunk cost and the opportunity cost to switch to a new one. This happens all the time in the public sector, or in sectors where operational complexity is high. Imagine you’re a public hospital who wants to buy a new software that improves your patient health records, allows you to make better clinical decisions and saves your doctors and frontline staff’s time, you still need to consider the implications of procuring that software, moving all your data across to the new system, training your staff to use it, onboarding patients and stakeholders into the system, securing it within your IT infrastructure’s operating constraints, amongst other switching costs. This moat by the incumbent is often referred to as **Vendor Lock-in**.

The same type of workflow integration happens with consumer products, but on an individual basis. If one invests years of their life getting all of their photos on Google Photos or Apple’s iCloud Storage, benefits from its integration with other Google/Apple services and devices, this will introduce switching costs when considering alternative solutions (if even they try to lower the burden of change). Similarly, once one builds a tight-knit pattern of friends and relationships within a social network, it is really really hard for a challenger to untie those in a format that encourages users to switch. The costs are just too damn high!

This often happens by coming up with a completely new format (think Instagram’s filters), or disrupting the incumbent in one key dimension that’s critical for a niche segment before expanding to mass market. More on this in counter-positioning.

**Cornered Resource**

Cornered Resources typically happen by fiat, i.e. by decree, by natural emergence or prescriptive influence, by virtue of one of the competitors having accessed a resource that isn’t accessible by others in the market for some reason that then constitutes an unfair advantage vs their competitors.

This is arguably the case with state-sponsored oil companies in the Gulf region, which have been given regulatory rights to explore a scarce commodity with worldwide demand, rights which may not be shared or democratized in access with any competitors.

 ![1_xf32Wp1e8HO6sPLZ-aLP_w.webp](https://writing.colivetree.com/u/1_xf32wp1e8ho6splz-alp_w-BrjUoc.webp) 

This might also be the case with intellectual property, when knowledge or access to information is shared within a small group and constitutes a market advantage, and that group uses that information to productize it or turn it into services that are hard if not impossible (economically) for competitors to replicate. Pixar’s positional scarcity, aggregating knowledge, capabilities and resources that no other studios had. Disney’s early advantage on character building and their usage of those characters in theme parks is one such cornered resource which has now seeped into the streaming business with Disney Plus. Record labels’ possession of the rights to license the most well-known brands in the industry (allowing them to exercise power over distributors — what Tren Griffin calls “Wholesale Transfer Pricing).

Once you get a hold of a valuable resource (by virtue, by chance or even by malfeasance) and you corner the market for it, it becomes a competitive advantage that can be insurmountable for vast periods of time and allow you to accumulate capital advantages elsewhere. **That**, is power.

**Process Power**

One source of power that’s less visited but Helmer discusses in the book is Process Power. The obvious example is Toyota’s, and how the conditions to their success look unimitable from the outside, their processes have been emulated many many times since their popularization, they even worked with competitors directly to implement their key operating principles in their manufacturing plants (such as GM — see here), and yet their competitors never managed to achieve the levels of quality, efficiency and effectiveness of their Japanese counterparts. Numerous books have been written since on the Toyota Production System, their Lean manufacturing approach, the Toyota Kata, the Kaizen system for continuous improvement, and everywhere in the world, and across every industry, people have tried to replicate it and its principles with varying degrees of success. As a source of Power, though, its process as a key moat for Toyota, that allowed it to scale worldwide even in the face other regulatory and competitive obstacles that competitors and nation-states tried to impose on the company.

The reality many discovered — it’s what you do. Behaviors promoted and incentivized, codes of conduct, relationships, hiring processes and traits you optimize for. These are all a part of process power.

 ![1_o4JQkQrDydBWvGhkndldVA.webp](https://writing.colivetree.com/u/1_o4jqkqrdydbwvghkndldva-AoBwVb.webp) 

Process power can’t be replicated by simply following a recipe, there’s art and craft that’s been perfected over time to result in the right culture, making it hard to replicate, and thus constituting a moat.

It’s the corollary of all things spoken and unspoken in corporate culture, that result in thousands of purposeful micro-decisions within the process framework that sustains the innovative approach and the results that it contains.

Recently, with Agile, Lean, and a culture focused on speed of iteration and experimentation (enabled by software, which drastically lowers the cost of change and whose micro improvements can be continuously absorbed by the market), the process power gap has closed in new industries, and many have tried to copy each others’ processes resulting in more or less a consensus as to how to build an amazing software company at scale. Even then, cultural differences come to the fore, and as a result of that optimization, different capabilities emerge. As Michael Porter described, in talking about what is NOT process power:

> “Operational effectiveness is about things that you really shouldn’t have to make choices on; it’s about what’s good for everybody and about what every business should be doing.”

There’s a clear difference between what Amazon, with its 2-pizza team-size rules, its API Mandate as a template for organizational change, making them their primary means of communication, decentralizing communication and allowing them to move forward independently, enabled Amazon to become competitive in multiple different areas, diversifying their offers and their revenue streams and strengthening their moat as an ecommerce leader and a commerce logistics & fulfilment platform.

Many have tried copying these processes blindly, in hopes that it would give them a competitive advantage, and failed. They failed in the same manner others failed in trying to implement a founder-centric decision-making process, in the hopes of emulating Steve Jobs and his design-centric critique process at Apple during the invention of its most successful products. Hard-to-copy, emergent, true to their nature and context, deeply connected to the roots of its company’s nature, that the source of process power.

**Branding**

It’s easy to talk about the power of brand for established household names. Coca-Cola, Nike, Heinz, Apple, IKEA, Hermès. They’ve created emotional connections to their names through years of repetition and carefully written marketing narratives that changed perception of their products from their functional utility to their emotional resonance.

The three key effects of brand power are 1) that they can be used to reduce price elasticity of demand, with brands acquiring pricing power over consumers and selling a product with similar features for a higher price (as a result of consumers being able to signal their affiliation through product use, which translates to how they are themselves perceived). 2) that they make lower the cost of retention / loyalty, with customers coming back to purchase again based on that sentimental affiliation, less than an objective preference function. 3) that they lower acquisition costs, with power users becoming some of their most passionate advocates, and the mass market customers following revealed preferences of this more passionate group by mere pattern recognition. For these customers, the decision-making process is vastly simplified, since they can follow the curated preferences of the advocate group and take that as signal of a certain product’s superiority.

 ![1_xo30te2lFVmqMBP_-oLSPA.webp](https://writing.colivetree.com/u/1_xo30te2lfvmqmbp_-olspa-yO6Hho.webp) 

These human biases and cognition pitfalls have hardly been changed by internet economy dynamics, although it is important to acknowledge that in many product categories, with low product differentiation, aggregators have more than ever built brands that commoditize supply. Customers will buy any brand of electronics on Amazon, will follow any top result on Google, will visit whatever service business has 5-star reviews on Yelp, will buy any jacket they like on ASOS. This is an effect of the age of abundance. Commoditization of supply and the large power of aggregators on the internet has created defaults for distribution that customers resort to without much acknowledgement of the underlying brands.



However, this has also meant that many highly specific, scarce niche winners have emerged. High quality goods, or brands highly indexed on a particular trait (e.g. sustainability, style) have emerged, and dominated narrowly defined categories, that still capture a large share of consumers’ wallets. In retail clothing, new luxury brands like off-white, supreme and Yeezy have emerged. Tesla in cars. The rise of D2C brands like Warby Parker, Glossier, Away, Patagonia and others solving highly specific problems for a particular segment or demographic talk to the power of brands, even in the age of commoditization. We’ll see how well these brands can continue to craft their narrative and guaranteeting dominance over prospective challengers in each of their categories (which are quick to spin up and try to gain market share, with the cost of starting new brands coming down via automation and the democratization of supply chains, as well as the accessibility of good design).

**Counter-positioning**

The last power we’ll talk about is the closest to Clay Christensen’s disruption theory, in my view, and the one that more closely relates in definition to differentiation. Ryan Singer describes positioning as:

> A product’s position is a “location” in a more abstract space — the space of trade-offs. The decisions you make about which features to build and how to integrate them places you “closer” or “further” from other products.

Of course positioning isn’t a new marketing concept, but Ryan is spot on when he identifies it as a place occupied in an abstract space that is also inhabited by your competitors. From any of your customers’ perspectives, your positioning is the space you occupy or end up occupying in relation to other brands and products that serve a similar or adjacent need/desire. To start quoting Christensen:

> Questions are places in your mind where answers fit. If you haven’t asked the question, the answer has nowhere to go.

Customers will be looking to make progress on a given Job-To-Be-Done, and your product’s position will ensure it fits better (or worse) with that JTBD in the customer’s mind, informing your decision-making in the process and also moving you closer to others who position themselves similarly.

This ability to distance yourself from the existing mapping of the solution space, is one of the key principles of innovation. In particular, disruptive innovation, offers you a lens into product positioning where disruptive companies often counter position themselves to incumbents by drastically improving the product in one key dimension, while maintaing relative inferiority in others, which incumbents are still optimizing for, since their existing customer base continues to value them.

 ![1_Q4k6ftqiGPWxQvE1W0YmOw.webp](https://writing.colivetree.com/u/1_q4k6ftqigpwxqve1w0ymow-oEyAXD.webp) 

This, then, takes us to one of Disruption Theory’s key insights: incumbents get disrupted by doing the right thing for their customers, not by being negligent of their needs.

It is simply that they are unable to optimize for an emergent segment, which values the disruptive dimension, while trading-off others that are over-served by the existing competitive landscape. This allows disruptors to underprice, grow rapidly and more nimbly with a given segment and attack new emergent market facets faster than their competitors can respond to them, and grow through hyper-specialization in relation to the type of value chain that is being designed by the market agents.

Counter-positioning also is a way to develop one of my favorite concepts, that of building your own proprietary distribution channel, fueled by your hyper-fit with a target segment’s needs. This, in Sam Altman’s view (at YCombinator), is how to grow huge. Tap into a fast-moving, high-reach distribution channel, and use the love of your key advocates to optimize your distribution. This, again, speaks to how these trade-offs can make your product occupy the space in customers’ minds where you are seen as THE solution to one of their needs, instead of one of the solutions to some of their wants. That, is power.

Tools

A tool to maximise learning when going from customer motivations to execution. A simple canvas to visualize your team’s work to discover, execute and integrate around the job to be done.

**The call of progress**

The Job Canvas starts from the Job To Be Done. It assumes you have talked to customers, collected insights from the data at hand and explored the dimensions of the problem you’re trying to solve — and then summarized it in the Job To Be Done format. I’ve typically gone for Alan Klement’s proposal and chosen <Situation> <Motivation> <Expected Outcome> as the cornerstones of my Job Story. This short format can encompass known trajectory (with situation), pain points (with motivation) and rightly focuses on outcomes (vs outputs).

**So what does the Job Canvas do?
**
You would hire the Job Canvas to help your team outline the key steps and measures you’re using create a solution that can itself be used for the job you’ve identified. These define the state of what you know in the context of what we are building — there should be other competitors out there, even outside our product category, competing to solve that same JTBD, so this applies specifically to how you’re thinking of solving it.

 ![1_lNwXzZbWV071ARVbXYalkw.webp](https://writing.colivetree.com/u/1_lnwxzzbwv071arvbxyalkw-o2YNKn.webp) 
> The Job Canvas template

So starting from the top-left, you find:

**Insights**

What do we know about the problem, do we have quantitative or qualitative data, have we talked to users, are there complaints we’ve received or customer support nightmares, interviews we’ve made, surveys we’ve ran?

**Hypotheses**

What are our assumptions underpinning a potential solution. If a customer is looking for something chunky to fool her stomach during the morning commute, that could be a Protein Bar, a sack of peanuts, a milkshake, a piece of fruit or even a magazine or a game that takes their minds off of food until they reach the office. We can hypothesise that certain features of our solution will get the job done.

**Success**

What happens if we achieve the impact we’ve defined? This should typically be quantifiable. Activation rate is up. NPS is up. Failed searches are down. Customers buy more, complaints go down. Define your Overall Evaluation Criteria upfront and only change it if the problem/job does as well.

**User Experience
**
It helps to have a clear picture of what your belief is “today” of how you’re going to solve that job. It could be a rough mock or a high-fidelity prototype, depending on where you are in the Product Development lifecycle. It should change over time as you discover, but it describes the type of end game you are visualizing, so your team has a common understanding of what they’re iterating on (or towards).

**Experiments**

Finally, I’ve designed the Job Board to make progress by means of experimentation. Anyone that has developed anything for people knows that product development isn’t linear. We learn as we go. Melissa Perri refers to this process as the Product Kata, but there are multiple experiment-driven approaches to product development. Bear in mind that this doesn’t necessarily have to include a controlled (AB..n) test, although that is a natural candidate for this job. This section is where you’ll describe what you’re doing to prove/disprove your hypotheses. Using a description like that in the Hypothesis Kit is very useful and gives you the consistency you likely need.

**Working through the problem space
**
Product Managers are awfully aware of the consequences of the application of the Red Queen effect to technology. The landscape around you is changing and accelerating as you create and learn yourself, leaving you with that bittersweet taste of always having more work to do than what you’ve already done.

So the Job Board is not a beautiful piece of art you and your team create in an afternoon and can then be encased in glass to be admired. It’s a living organism you print, tack onto a wall or a whiteboard, make changes to as you learn more about the job, get more insights and redefine your success criteria.

**A working example
**
> You’re an on-demand food delivery startup with some traction. You’ve talked to your customers and they’ve told you that things work well for them when they’re alone, but when they have friends over, they need to order larger quantities of food easily — an competitor for the job would be to just go out for burgers or call Domino’s.

**JTBD**

When I have friends over and don’t feel like deciding what and how to cook something, I want to get something easy and filling, so we can get on with playing Cards Against Humanity the rest of the evening.

**Insights**

“80% of our orders are single-servings”, “Our funnel drop-off rate when people are ordering multiple servings of the same product is 50% higher”, “In user research, people report making multiple orders when they have friends over”

**Hypotheses**
1. Based on the insight that 20% of our offers are for multiple servings, we believe that by introducing a Group Deals category we will allow people to easily find food for their group of friends, simplifying their selection process after a search.
2. Based on the insight that people report making multiple orders when they have friends over, we believe that letting people order from multiple restaurants at once will allow us to better serve groups, increasing conversion rate for these orders.
 
**Success**

We will see a positive impact in conversion rates for people ordering multiple-servings.

In the 1st month following launch we will see the total number of orders by our “group-orders” cohort increase by 10%.

**User Experience**

 ![1_2zadrVBjFJpNLavONqLoow.webp](https://writing.colivetree.com/u/1_2zadrvbjfjpnlavonqloow-A9pqPG.webp)  ![1_tbmZ9h-15cwlFsJs11hgfg.webp](https://writing.colivetree.com/u/1_tbmz9h-15cwlfsjs11hgfg-Haaw6H.webp) 

**Experiments**
We predict that by creating special Group Deals based on aggregating offers, we will help people find large portions to feed a group for the night. We will test this by introducing a Group Deals CTA and assuming the change has no effect (the null hypothesis) and running an experiment for 2 weeks.If we can measure a 5% statistically significant change in search to conversion rate, then we reject the null hypothesis and conclude there is an effect.

**Finish your order**

 ![1_2zadrVBjFJpNLavONqLoow.webp](https://writing.colivetree.com/u/1_2zadrvbjfjpnlavonqloow-Yl8mrV.webp) 
> An example early stage Job Canvas

The Job Canvas is never finished. While your team stays focused on solving problems gravitating around a key job-to-be-done and while customers are ditching your product for competitors, there is work to do. The Job Canvas gets updated, new insights are collected, your success criteria evolves and new experiments are launched. Your User Experience prototypes go from low-res to high-res and your team grows with the canvas as it evolves. 

# The Product Playbook
A Playbook of Product Management Techniques

## Intro
A Product playbook is something I've wanted to do for a very long time.
Product management is an art, insofar as everything that requires human intervention to create something is art. But there is causality in what product people do and their outcomes, how the interactions between product managers, designers, developers and other stakeholders turn vision into usable objects or interfaces. This playbook aims to become a cooperative effort to describe the multiple ways one can turn insights and ideas into products that solve problems.

The concept of the playbook is inspired by sports. The best explanation I've seen is the one by Jon Lax in ["Great Products Don't Happen By Accident"](https://medium.com/great-products-dont-happen-by-accident/great-products-dont-happen-by-accident-f46323d8ad94)

The product playbook gives people plays they can apply to specific moments in the product development workflow. Each play should follow the same easily readable format and should be easy to pick-up and follow. Some of these plays originate from companies like Google, Facebook, Amazon, Intercom, Spotify, Amplitude or Basecamp and used industry-wide, others have been developed by individual practitioners, tried and tested in the field and represented here.

Some of the companies that openly share how they develop product are:
* [Atlassian](https://www.atlassian.com/team-playbook/plays)
* [Intercom on Product Management](https://www.intercom.com/books/product-management)
* [Basecamp - Getting Real](https://basecamp.com/about/books/Getting%20Real.pdf) / [Basecamp - Shape Up](https://basecamp.com/shapeup) 

There are also these fantastic lists of everything product:
* https://github.com/tron1991/open-product-management
* https://platformsandnetworks.blogspot.co.uk/p/resources-product-management.html
* https://www.sachinrekhi.com/top-resources-for-product-managers
* https://www.lennyrachitsky.com/p/my-favorite-templates-issue-37?u

## The Plays

### Vision & Strategy
* [Product brief](https://github.com/colivetree/product-playbook/blob/master/product_brief.md)
* [Positioning](https://github.com/colivetree/product-playbook/blob/master/product_positioning.md)
* [DIBBs](https://github.com/colivetree/product-playbook/blob/master/DIBBs.md)
* [Working Backwards](https://github.com/colivetree/product-playbook/blob/master/working_backwards.md)
* [One-pager](https://github.com/colivetree/product-playbook/blob/master/one_pager.md)
* [7 Powers](https://github.com/colivetree/product-playbook/blob/master/7_powers.md)

### Goal Setting
* [OKRs](https://github.com/colivetree/product-playbook/blob/master/OKR.md)
* [Metric Pairing](https://github.com/colivetree/product-playbook/blob/master/metric_pairing.md)
* [HEART & Goals, Signals, Metrics](https://github.com/colivetree/product-playbook/blob/master/heart_framework.md)
* [North Star Framework](https://github.com/colivetree/product-playbook/blob/master/north_star_framework.md)

### Product Discovery
* [Design Sprint](https://github.com/colivetree/product-playbook/blob/master/design_sprint.md)
* [User Testing Sessions](https://github.com/colivetree/product-playbook/blob/master/user_testing.md)
* [JTBD Interview](https://github.com/colivetree/product-playbook/blob/master/jtbd_interview.md)
* [Opportunity Solution Tree](https://github.com/colivetree/product-playbook/blob/master/opportunity_solution_tree.md)

### Alignment
* [Product Increment Sessions](https://github.com/colivetree/product-playbook/blob/master/product_increments.md)
* [Story Mapping](https://github.com/colivetree/product-playbook/blob/master/story_mapping.md)
* [Job Canvas](https://github.com/colivetree/product-playbook/blob/master/job_canvas.md)

### Testing
* [Experimentation](https://github.com/colivetree/product-playbook/blob/master/experimentation.md)
* [Riskiest Assumption Test - RAT](https://github.com/colivetree/product-playbook/blob/master/riskiest_assumption_test.md)
* [Confidence Check](https://github.com/colivetree/product-playbook/blob/master/confidence_check.md)
* [Design Critique](https://github.com/colivetree/product-playbook/blob/master/critique.md)
* [Dark Launch](https://github.com/colivetree/product-playbook/blob/master/dark_launch.md)

### Prioritising
* [Reach Impact Confidence and Effort - RICE](https://github.com/colivetree/product-playbook/blob/master/prioritisation_rice.md)
* [Sankey Diagram of Needs](https://github.com/colivetree/product-playbook/blob/master/sankey_diagram_needs.md)
* [Action Priority Matrix](https://github.com/colivetree/product-playbook/blob/master/action_priority_matrix.md)
* [Bugs, Technical Debt and Broken Windows](https://github.com/colivetree/product-playbook/blob/master/prioritising_bugs.md)
* [Kano Model](https://github.com/colivetree/product-playbook/blob/master/kano_model.md)

### Validated Learning
* [Spikes](https://github.com/colivetree/product-playbook/blob/master/spikes.md)
* [Melissa Perri's Product Kata](https://github.com/colivetree/product-playbook/blob/master/product_kata.md)


## Contributing to the Product Playbook
* [Play Format](https://github.com/colivetree/product-playbook/blob/master/template.md)
* [Guidelines for contributing]


I recently put together a list of articles, videos and books I think people moving into a product role should read to get a good grasp of the fundamentals.

These are just a starting point to help new Product Managers / Owners / Humans think about problem-solving in the internet age and give them mental models. If that’s you, you’ll need to know that they’re not recipes but, in time, they can help you create your own. In the end, building things people care about is hard work, and it’s all on you. Good luck!Articles / Essays

**We don’t Sell Saddles Here
**
Stewart Butterfield, Slack’s CEO, wrote this brilliant memo 2 weeks before Slack launched. It’s about the meaning of what you’re building. That matters a whole lot more than what the product says on the tin: https://medium.com/@stewart/we-dont-sell-saddles-here-4c59524d650d#.ldajcg1ds

**Thinking Exponentially — 10x not 10%
**
Ken Norton, now a partner at Google Ventures, explains why Product Managers should always be the strongest advocates for disruption: https://www.kennorton.com/essays/10x-not-10-percent.html

**What makes a great Product Manager
**
Piero Sierra, VP of Product Management at Skyscanner and formerly a Director of Product at Skype, has a look at the key traits of a great PM: https://medium.com/@pierosierra/builders-make-the-best-product-people-22fdb8d75dfe#.jdjcefyf0

**Solving the right problems
**
Melissa Perri, one of the leading thinkers in Product, asks us to escape the very common trap where companies think they’re making progress by keeping people busy. Here’s how to focus on making sure we’re solving real problems for people: https://www.mindtheproduct.com/2017/07/escaping-build-trap-melissa-perri/

**Speed of iteration beats quality of iteration
**
This one took me a while to fully absorb. I wholeheartedly disagreed with it at first, but then slowly came around to loving this. Jeff Atwood, creator of StackOverflow, builds on John Boyd’s airplane fighting teachings and explains that learning fast, starting small and iterating constantly is the way to survive: https://blog.codinghorror.com/boyds-law-of-iteration/

**Do things that don’t scale
**
Premature optimisation kills great ideas. To get to Product-market fit, you need traction. To get traction you need to do things that allow you to learn about your customers faster than the competition before you run out of your scarce resource (often money). This, by Paul Graham, is a classic: http://paulgraham.com/ds.html

**Finding Product Market Fit
**
Marc Andreessen at A16Z is next with another future-proof essay about how finding product market fit is all that matters when building something new: http://pmarchive.com/guide_to_startups_part4.html

**How to start a startup
**
The whole How to Start a Startup series, organised by Sam Altman at Y Combinator, is full of gems from great speakers. Great content like this wasn’t free 10 years ago: http://startupclass.samaltman.com/

**What do you actually do?
**
Great products don’t happen by accident, by Jon Lax, a Director of Product Design at Facebook has influenced me heavily. Now, when faced with a new situation, I try to think of the tools at my disposal. If I don’t have one that works, I try to find one or create it. A good playbook is essential for Product Managers: https://medium.com/great-products-dont-happen-by-accident/great-products-dont-happen-by-accident-f46323d8ad94#.pj1236nkd

**Working Backwards
**
If you want to build great products, start with the end goal. Amazon’s technique is now super well-known and if you want your team to fully understand the problem, even before writing a single line of code, it’s worth giving it a shot: https://medium.com/bluesoft-labs/try-an-internal-press-release-before-starting-new-products-867703682934#.734z4kt4w

**Should you really build that?
**
Sean Rose, Product Manager at Slack, once tweeted this quote from Neil Hunt (CPO at Netflix) and it just perfectly summarised what I felt about getting stuff in front of user. Removing complexity is key to building great products.

**Where does your product stand?**

When people talk about Unique Value Propositions or Unique Selling Points, they often mean this. Ryan Singer is a brilliant thinker and his “Position, Position, Position” essay makes a great argument about establishing yourself clearly through trade-offs. If you do X, instead of equally defensible Y, you’re immediately going to be different from anyone else doing it. If you do it across a number of dimensions, you will have found your place. Read it: https://m.signalvnoise.com/position-position-position-34b510a28ddc#.m6ggr5p3a

**There’s no Process Silver Bullet
**
Kent Beck is one of the 17 original signatories of the Agile Manifesto (very much worth reading and comprehending) and literally wrote the book on Extreme Programming. This is how we sees Agile and software development processes, 20 years later, through the lens of his 3X framework: https://www.youtube.com/watch?v=YX2XR73LnRY

**Internet Economy 101
**
Ben Thompson is the business analyst you need to follow. His masterpiece is aggregation theory, a unified reference to grasp all great internet economy companies: https://stratechery.com/2015/aggregation-theory/

Follow that up with his new piece on Defining Aggregators, and just follow Stratechery.

**Abundance in the internet world
**
Read this series by Alex Danco at Social Capital, to build on what Ben Thompson has taught us and really start grasping how the internet has changed everything. You’ll need this to understand how your customers operate.

**The role of culture
**
Netflix’s genius culture deck is a masterpiece to understand how companies can scale, how to attract the best talent and keep them engaged. Culture eats strategy for breakfast (originally said by Peter Drucker), the Netflix version: https://jobs.netflix.com/culture

Also look at Spotify’s (and now everyone else’s) organisational design.

**How Google sets goals
**
Rick Klau talks about setting goals and tells you all about OKRs: https://www.youtube.com/watch?v=mJB83EZtAjc

Pair (pun intended) Rick’s video with this on paired metrics and how single metric blindness can kill you: https://mattyford.com/blog/2014/6/11/paired-metrics



**Books**

**The Lean Startup**

Let’s get it out of the way. Read the Lean Startup. It’ll help you understand everything else about product development.

**Thinking Fast and Slow
**

If you want to understand how users think, you need this intro to Kahneman and Tversky’s work. It’s fascinating.

**Influence**

The six principles of persuasion laid out by Cialdini will help you look at your most beloved products in a completely different lens. Read it and see them everywhere.

**The Design of Everyday Things
**
You’ll need to talk to designers. You’ll need great references about how people interact with the world around them. You need deep sensibility about product design and attention to detail. Don Norman is your guy for every one of these.

**Zero To One
**
Peter Thiel doesn’t think of innovation like others do. He doesn’t think of competition like others do. He thinks of starting things as either zero or one. Winner-takes-all, is actually all there is. A new mindset.

**Innovator’s Dillemma
**
This is another classic on the nature of innovation and how making the rational management decision every time will ultimately kill your company. The Innovator’s Dillema is now (2017) 20 years old, but it is perfectly timeless.

**Competing Against Luck
**
Understand jobs-to-be-done, why people purchase products and how to solve for their deeply rooted motivations and goals. Clay Christensen advocates that there’s a better way to build products than trying out everything and seeing what sticks.

**Creativity, inc
**
Building a culture of creativity, candor and growth to become one of the world’s most successful animation studios ever. The story of Pixar by Ed Catmull is fantastic.

**Steve Jobs by Walter Isaacson
**
Isaacson is an brilliant storyteller and he gets Steve Jobs, the good and the bad. Don’t read this to become Steve Jobs, read this to understand how one of the most brilliant product creators of all time thought about the world. In the Company of Giants also has some amazing insights into Jobs’ incredible mind.

**Sprint**

Going from idea to testable prototype in 5 days from Jake Knapp. Do one and get hooked on testing ideas and failing fast.

**The Mom Test
**
At the end of your design sprint, you’ll need to ask your customers the right questions. Read the Mom Test to understand what never to ask.

**Hooked**

By Nir Eyal as an intro to engagement loops.

**The Hard Thing about Hard Things
**
Because nothing is easy about building product and Ben Horowitz knows it better than anyone. This books is an incredible account of Ben’s journey as company founder and product builder.

**Rework**

The guys at Basecamp (Jason Fried, David Heinemeier Hansson) know perfectly well that everything people say “is the way it has to be” about building a company is wrong. In fact, they’ve built a great company that proves it.

AI In the Middle
Observability, Evals, Memory, RAG - The best PM in the world has severe memory loss
Human in the loop
Processes, their language, shared history, culture and org memory
The way things improve
What's been hard will stay hard