## Description
- Specialisms exist for a reason

## Disproof
- Some meetings where the designers aren’t opining on the financial modelling or the product managers aren’t suggesting a migration strategy to Redis

## Consequences
- Groupthink means your product will be mid
- If people are wasting time on managing conflicting opinions instead of deeply solving problems, the result will be shallow solutions
    - Anything ‘special’ will be sanded away in favour of a norm
    - Just like users, you won’t please all stakeholders and will produce mediocrity by trying
    - If your product is mid, someone else will solve the problem better. You lose users and your jobs
- If the whole company sat around picking the best font or something, you burn time
    - Specialists are most productive in their specialism, if everyone is spens all their time in discussion / planning, nobody’s working
    - If the trust in each other’s specialism isn’t there and you’re also spending time justifying the choice of button colour to the finance team, you’re wasting more time
    - Waste enough time that you move slowly enough to have your lunch eaten, nobody has jobs
- At the very least, a sense of entitlement arises which is just fucking annoying to deal with and wastes time

## Causes
- Within product, some smartass got hurt by waterfall and decided the antidote was that everyone does everything all at once because everyone’s opinions on every stage are as needed as everyone else’s
- At a company level, when a silo’d product team went and yeeted something into prod without consulting non-product stakeholders. A ‘never again’ moment happened and it was mandated that lawyers and HR sit in code reviews.

## Approaches
- Recognise when upstream mistakes lead to knee-jerk overcorrections
- Acquaint everyone \(including the specialist doing the work\) on the consequences of not having deep thought
    - Obviously if pairing makes sense, pair up. This is a much bigger problem at the refine and design stage than execution
- If you’ve hired good people, remind everyone that they are good people and to have the stones to stand by their work
- If you’ve created a toxic environment where nobody has the confidence to do truly extraordinary work, the work will be extra ordinary
- If you’ve got an auteur whose tastes must be appeased for anything to pass review, make sure those tastes really are best for the company

Always involving everyone

## Description
- Most time spent answering questions is lost, especially if those questions are repeated

## Disproof
- Dashboards and docs that people actually use first

## Consequences
- When engineers are DM'd for delivery status, engineers start losing 20% of their day from interruption and context switching
    - Surprise surprise, delivery takes 20% longer and anyone whose work is scheduled on the original delivery time, proceeds to get rekt
- When PMs are treated as living product/marketing documentation, other teams learn helplessness, creating a reinforcement loop
    - Suddenly PMs don’t add value anymore because time that could be spent on real product work is burnt
- Status questions thankfully go away, but 'how to use' and 'how to sell' questions represent an evergreen time sink
- Eventually, organisational fitness is lost to the point where it is outcompeted, and dies


## Causes
- When nobody has explicitly thought about what information is needed by who
- When it’s been normalised to ask people questions that a transparent and easily locatable document/tracker/dashboard could answer
- When a product team has developed an allergy to ‘feeling watched’, and doesn't propagate status outwards
    - Usually due to bad relationships with the rest of the company, or historical micromanagement, and as a result, under-reports status
    - Ironically, the only way the rest of the company has for understanding what’s going on is to interrupt by polling for status, making product people feel more watched
- Things further slow down if there’s no standardised way of reporting status and you’re making things up every time someone asks a similar thing
- In the case of 'how to use/sell' questions, can be when product teams are too busy or not taking responsibility for the end result of actually getting documentation used by making them relevant/readible/findable

## Approaches
- If a company’s culture has evolved in such a way that it’s OK to do this, it’s going to take a lot of butt-hurt and boundary-setting to claw people back to it
- Design something truly appropriate for the work you do and for who needs to know
    - Any solution that has not properly anticipated the information _needs_ of its consumers \(i.e. everyone else in the company\) will fail because it won’t tell them what they need to know
    - Any solution that doesn’t build a habit in its consumers will fail because they won’t remember to use it
    - Any solution that has not properly anticipated the need for the product team to not do pointless paperwork will fail because they won’t fill it out

Answering predictable questions

## Description
- It’s called debt for a reason - if it’s not paid down steadily it comes due all at once and you lose your house

## Disproof
- Unified technical and feature planning, always

## Consequences
- You will have a lot of explaining to do at the best, and existential problems at the worst
- Compounding tech debt presents the same dynamics as error propegation in untested product hypotheses. Each successive kludge you leave in multiplies the risk of a showstopper or show-killer. Invariably, something either:
    - Breaks in production and you lose money and customers
    - Breaks before production and you lose time, money and potentially customers
- Whenever you hit the landmine that you can't just soak up, you then lose the next few months of ‘progress’ fixing it
    - In reality, you never had this time in the first place
    - But it reaaally sucks having to explain to your customers and shareholders why your rapid pace of shipping has ground to a halt for some quarters
    - Especially if commercial deals or investments ride on said shipping

## Causes
- Move fast break things?
- The irony of a ‘damn the torpedoes’ approach will usually work _juuuust long enough_ to give people confidence that it will always work. As you get away with it, you think you’ll keep getting away with it
- Generally exacerbated by a structural disconnect between people prioritising work and people who understand the infrastructure
    - Happens very often with PMs who are not remotely technical and have a bad relationship with the tech leads
    - Also happens with overly atomised teams where nobody’s keeping track of debt across the technical estate
- In cases where tech debt is deliberately downplayed, it's usually because someone over-engineered a refactor, got blamed for wasting time, and the team over-corrected


## Approaches
- The one case you might be lucky is where your engineering team growth can outstrip the rate at which you create errors in your infrastructure.
    - But if you're this kind of company, almost invariably those engineers will be diverted to do more feature work instead of creating capacity to fix tech debt
- If the communication is not there between engineering and whoever needs to know, that is top priority.
    - Communication includes it being safe to voice these needs
    - Communication should also be backed up by facts and quantification, because otherwise ‘the cranky engineer’ who’s always ‘crying wolf’ just gets ignored again
- As with agricultural land generation, get ready to see ‘productivity’ fall briefly and then accelerate. Sell people on the latter half
- And if this is just a case of forgetting to think about it, stop relying on Hope as a Strategy

Didn't factor tech debt

## Description
- Done is a verifiable state of affairs that everyone has agreed to. This is not about defining success, this is purely about agreeing what you will ship, when and in what phases

## Disproof
- If you're a BDD baller, just have everyone agree on the test suite. Or a very unambiguous statement of what capabilities, by what time

## Consequences
- Multiple imagined timelines based on different pictures of what’s being built
- A tendency for customer facing teams to over-estimate what’s being built and underestimate the time to build it, resulting in mismanaged expectations
- Destruction of trust and cohesion as, after non-product teams wait for weeks blissfully unaware that their expectations have been mismanaged, v1.0 turns out to be their v0.1
    - People act unprofessionally, communications break down, the company wastes money or gets outcompeted into an early grave

## Causes
- Sometimes, product teams just want to be rock’n’roll and freestyle it, thinking that the only alternative to massive waterfall specs is to have no specs. This is stupid, stop that
- Sometimes, stakeholders use ‘acceptance testing’ to simply cram more and more things they want in there. Maybe they’re right, maybe they drastically misjudge the value that they’re trying to add to the product

## Approaches
- Everyone whose job depends on a delivered product should at least be appraised of what ‘done’ means, this time around
- And some stakeholders will always want more than is reasonably doable in time
- And that is why 'done' needs to be negotiated ahead of time or we simply kick that problem down the road
- Try locating each stakeholder's true constraints (at what point can they _really_ not support, do manually, sell or fund something)
- In any case where you get an agreement, don't surprised if people forget it or willfully try to overreach it. Don't be afraid to remind people of why we have agreements

Didn’t agree a ‘done’

## Description
- Hoping that someone's doing their job (or even knows which part is their job) is rolling the dice with everyone's jobs.

## Disproof
- A verifiably transparent workflow that progresses without reliance on human memory

## Consequences
- Hoping the team will correctly de-risk \(checking with stakeholders, compliance, etc\)
        - It’s just a matter of time before someone forgets or judges that it’s ok to not
        - Something blows up, costing the org money or reputation (i.e. the ability to get money)
        - If that happens enough, we don’t have jobs anymore
        - Hopefully, it’ll be minor enough for you to learn and then stop relying on trust
- Hoping specialists all perfectly communicate the readiness of dependencies for other specialists to then pick up \(test writing, documentation, localistion, marketing plan etc\)
        - Asynchronous parallel workflows become synchronous series
        - Time wastes, money burns. If that happens enough, we don’t have jobs anymore
        - Hopefully, delays will be minor but annoying enough for you to then do something about it
- In the case where nothing is even being tracked manually, the only way to get a complete picture of what’s happening is literally going around asking everyone every day. Hilarity ensues at scale as armies of people get hired to go around with clipboards.

## Causes
- “Everyone is an adult professional that has the team’s interests at heart and will ensure no ball is dropped”. Wrong:
        - Stress, workload, switching costs, trying to do too many things at once cause people to act rashly or forget to act
        - People also are perfectly entitled to work their allotted hours and not do anything not explicitly asked of them
        - Unfortunately, making sure that everything is done across the board lies very much in the extra mile. Generally you’re not going to be paying people enough or doing something important enough to go it.
- Typically though it’s just because you blinked and grew past the scale where everyone can fit in one room and keep everything in mind at the same time.
        - Tends to happen after a funding round when you’re encouraged to “deploy capital” and “scale resources”
- Most organisations also lack anyone skilled at org arch or process analytics 


## Approaches
- Continuous integration has come a long way. Multidisciplinary work has not. 
    - Instead of relying on someone remembering what to do or even following a checklist, automate the checklist.
    - Automate alerting when the checklist isn’t followed.
    - Automate telling people they’ve got new work to do
- If you’re afraid that nobody will listen to the automated checklist, do two things:
    - Design an actually decent process that solves the specific problems of your product org.
    - Crib from best practice but by god if you use scrum with a bunch of greybeards you’ll just piss people off
    - Acquaint them with what happens when a fuck-up occurs due to an ignored checklist

Hope as a strategy

## Description
- Full steam ahead! Will the current build lead to another stepping stone in the direction of the mission or off a cliff? Who knows?

## Disproof
- A pool of things you can’t build now, but that building this enables. Doesn’t have to be linear, doesn’t have to be a roadmap

## Consequences
- Each option past what you’re doing now will have a huge amount of probabilities assigned to it that only coalesce once you’ve shipped the current thing
- If you’re betting on a totally linear path, you will at some point have to think very quickly
    - If you’re betting the farm on the totally linear path, you may lose the farm
- If you’ve not thought about a path at all, you could build something that actually kills your ability to progress
    - Your users get used to a local maxima
    - The next product conflicts with it
    - UX creep, plurality of paradigms, no space for expansion, trained users to expect the wrong thing, etc

## Causes
- Likelier in the absence of a dedicated strategist; even if you’ve got the perfect team capable of distributed strategic thinking - they can still get distracted by all other processes that go into the build and fail to do this thinking
- However, even when ‘strategic’ thinking has been done and you have a roadmap, it has been imagined statically
    - Nobody has fully reasoned through the opportunity implications of each product or feature being built and operated
- If you’re too busy chasing funding - investors look for companies with a future not just a present 

## Approaches
- If you don’t have some kind picture of which stepping stones that get you towards the mission, which you can reach and which ones you can’t, and which is the shortest route, start there.
- Each iteration materially shifts the relationship you have with your users and what you can get them to do. It also alters your position in the market, the tech level of your company and the dynamics of the businesses operationalised around it.
- These things are rarely linear and it’s ok for it to look like a cloud. What WILL help to organise it is looking at each stepping stone and asking:
    - What needs to be reached first before this works?
    - What does reaching here change about my relationships and my company’s organisation?
    - What opportunities do I have from here?
    - What opportunities do I give up?
- If product leadership exists, it needs to stop doing busy work and lead this thinking.
- If product leadership doesn’t exist, someone is going to have to make it happen, even if they’re not the one doing the thinking

No next step

## Description
- I'm not telling you when it'll be done because last time we needed to move a deadline you had everyone flogged

## Disproof
- Everyone is willing to give time-bound estimates of what they’re doing, and everyone depending on those estimates is able to deal with estimates being off

## Consequences
- Non-product functions miss opportunity, miscommunicate to customers and generally not know when work is going to ramp up
- Because people take months to hire, non-product functions scramble and screw up as new things come online to support and sell, or burn money over-allocating resources in anticipation of a product launch that may or may not happen this quarter
- Working at the company starts to resemble early trench warfare. Nobody knows what’s happening, they can only live in tense fear of the next rush over the top and scramble the moment they hear the thump of the guns and the sounding of the bugle. Good people will leave
- Generally suffer efficiency losses as trust erodes, company gets outcompeted and dies

## Causes
- An environment where it is not safe to be wrong when unknowns cause delays, leading to learned helplessness of not even trying to estimate in the first place
- Being very principled about ‘can’t rush quality’ but forgetting:
    - The fact that money is not infinite and that the business needs to remotely look like a business
    - That all downstream activities need ramp-up time once something gets lobbed over the wall to document, translate, market, train support staff on etc
    - That there’s a little thing called competition and that lunches will get eaten

## Approaches
- It needs to be psychologically safe to give a loose estimate and refine it
- It needs to be psychologically safe to confirm progress towards a target
- The questions are always the same: “when will it be done?” and “how much is progress tracking to that estimate” but the people having this discussion are going to feel very different based on what environment it’s being asked in
- If something got mis-timed in the past and everyone is still bitter about it, you need to heal those wounds
- I repeat:
    - It needs to be OK to ask for an educated guess on when something will be done
    - It needs to be OK to say “that was a guess, here’s a new one based on more information” _as early as possible before the deadline passes_
- It is not a bad idea have at least 2 check-ins between start and expected finish. This is fundamentally because the earlier you know something is _not _going to be there at time T, the more room you have to adjust
- Also ensure that it’s not a case of perfectionism. ‘Perfect is the enemy of done’ can help unstick things if you're not being a prick about it
- Also ensure that everyone is damn well acquainted with the fact that they aren’t the only specialists in the company and that other specialists depend on them to know when they will need to do their jobs

No targets, no target renegs

## Description
- Every piece of work you do is a prediction. The amount you find out how wrong you are scales with time you fuck around

## Disproof
- Release and test stuff maybe?

## Consequences
- What is really counter-intuitive is that the incremental amount you can ‘perfect’ something (or try to anticipate and ‘pre adjust’ for a potential correction) tends to diminish per day, but that error tends to grow per day.
    - i.e. There’s a window for validation and correction. If you overshoot it, the pain is going to ramp much faster than you can anticipate and correct for.
    - e.g. spend 2 weeks building the functionality, then spend 2 more weeks polishing the CSS, but the problem was actually the information architecture in the first place. Ouch
    - In extreme cases, error feedback loops can happen where you actually get more wrong over time
- Contagion effects where entire other departments gear up around an expected state of affairs (e.g. prepping to internationalise something that might have to change drastically after its release)
- Releasing something actually bad after a long time, instead of something imperfect the can be fed back on after a short time, almost categorically loses more users
- Spend enough time backtracking or scrambling to fix something you should have released weeks ago and you risk running out of money, customers, goodwill, etc.

## Causes
- Almost always caused by some someone somewhere in the chain being scared to release something ‘unpolished’ for fear of blame/ridicule/personal liability
- If this fear remains, you’ll never change
- Most other times, someone doesn't want to 'tip their hand too early' and get outcompeted

## Approaches
- Correct the thinking and fix the fear of the unpolished with an even bigger fear of the consequences
    - Every prediction will have _some_ error in it. You find this quantity out by contacting reality \(both in test and in launch\). Once you know the error, you can correct it.
    - What should be obvious is that as time between prediction and contact with reality grows, so does that error. This means you’re almost always buying yourself a bigger correction the longer you go on uncorrected
- If you’re working on something that just takes a long time, and you have money, and people will entrust you with years of their time, go ahead. But most of us don’t have that, and even if we did there comes a point where you’re leaving time on the table.

Time spent uncorrected

## Description
- Switching tasks burns time in ramp-up. Cue unrealistic expectations and disappointment, especially if multiple stakeholders are asking for switches but aren't aware of each other

## Disproof
- An established system for deciding any change to in-flight work, and a way of communicating it

## Consequences
- If switching happens faster than the actual time cost of switching (invariably at least half a week), you get this lovely thing we call ‘thrashing’, where literally nothing gets done
- People assuming that a one week detour means a one week delay, undercompensate their own scheduling. Dependencies get fouled up, marketing pushes get misaligned, a whole bunch of nasty ensues
- A one-off won’t kill you, but repeats will torch internal and eventually customer trust
- As per usual, either move slow and die, or burn everyone out trying to maintain speed

## Causes
- People who, in 202X, still make it part of their personality to not understand how engineering works whilst working at a product company and somehow still seem have jobs
- When product teams have some kind of prioritisation cadence with individual departments, where someone weak-willed gets cornered by someone on a warpath
- If you’re in the business of making switches that you _know_ to be wrong but aren’t skillfully managing and preventing, it’s a psychological safety and skill issue. Effectively, you’re prioritising the shoutiest, but in-flight

## Approaches
- Changing direction before you hit ‘done’ can make sense if the priorities of the business have drastically changed
    - People should only be mad if this happens for a bad/avoidable reason
    - But if the original target is no longer viable, don’t waste more time on it
- If the diversion is only meant to be temporary, be extremely quantified about the cost of stopping, contextualising elsewhere, and then re-contextualising on the existing problem. This is often forgotten by anyone abstracted away from building \(investors, non-product teams, sufficiently disconnected leadership\)
- Train people in charge of defending prioritization to not buckle like wet cardboard, and also how to not piss people off when saying no

Unmanaged switching

## Description
- You know the game-changer feature is on the 3rd sublevel of the hamburger menu because you've spent all sprint staring at it. Your users, less so.

## Disproof
- A documented flow in which each user type gets to the point where they can even begin to derive value from the product

## Consequences
- If you're making this kind of mistake, you likely didn't just forget to tell people how to use your product, but also forgot to tell them why to use your product (see messaging).
- Nobody knows how to get value out of your product - which has the same consequences as not delivering value. Which means they don't use it and you lose cohorts worth of users which cost triple to re-aqcuire
- You also multiply errors as you double down on functionality that you don’t realise is useless because nobody’s used it yet, thinking you just need to keep building until it's 'complete'

## Causes
- Sometimes, a product that’s supposed to ‘self-teach’ via UI/UX ends up with the UI/UX dropped from the build to speed time to market
- Or the " we don’t need onboarding, we're talking to the users already every day" model that blows up the moment you scale past 5 customers. Unfortunately early success tends to blind you.
- In B2B products, tends to happen when the sales team flies solo because having anyone else (like, god forbid the people responsible for customer success or building the product) around would ‘slow things down’

## Approaches
- It doesn’t matter if you use an onboarding team or in-product tutorialisation. If you haven’t got a map of every learning step the user takes to understand how to get value of the the product, start there
- Any plan, be it via UX or AM, is useless if you haven’t sat down with actual users and built the plan around where they actually get stuck. Otherwise you’re both guessing at the value of the product and at how to get the user to that point

Assumed users just figure it out

## Description
- Not so much a 'build it and they will come', more a 'built it and it's marketing's problem now'

## Disproof
- A clear G2M that has been agreed with the people doing the going to market, even if those people sit in the product team and just buy facebook ads

## Consequences
- Your product, being not used, delivers no value. No value, no money, no jobs. You’ve succeeded at not building anything, just with more steps and money burnt
- Marketing, flying blind, starts making shit up and burns cohort after cohort of leads (and most of the cash budget in the case of outbound)
- Outbound sales either ‘can’t do their jobs’, or ‘take the initiative’ and start shifting weight. You’ll end up with the wrong, pissed off users with missed expectations, or very expectant ones that have been promised the moon in custom development

## Causes
- At any reasonable scale there will be someone whose job it is to not make the product, but to get the product into people’s hands.
    - Such a person is somehow assumed by the product team to be omniscient. This leads product to stop putting any thought or, god forbid, effort into it
    - This person is not, in fact omniscient and tends to do badly because they’re piecing together the target user and intended value of the product, etc. from the totally unorganised transient chicken scratch that passes for documentation /(which anyway omits half the key decisions given they were made in the pub after work one week/)

## Approaches
- What needs to happen is entirely dependent on who your users are and how they need to be communicated to
- Whatevery particular way your product needs to meet users where they’re likeliest to actually use it, make damn sure you’ve signed off on it
- Don’t necessarily do it, but make sure it’s done

Disregarded adoption

## Description
- “Expansion” sounds like just one thing. If it is to more than one country or vertical, it isn’t.

## Disproof
- This year’s top 3 strategic priorities aren't: address the long tail, expand to Europe & Asia, capture market adjacencies

## Consequences
- Underestimate complexity, miss announced launch, kill reputation
- Underestimate local regulations/cartels/culture/competitors/labour laws, kill branch offices, fire local teams
- Underestimate costs, kill company, fire everyone

## Causes
- The undisciplined pursuit of more by anyone that has seen lighting strike once
- Assuming that everything you already know will just translate with zero lift when jumping into a new vertical, customer segment or territory; sometimes literally forgetting translations
- Investor assumed they were buying a money printing machine that ‘only' needs to replicate success in 5 other geographies markets. Probably loaded the company up on debt to do the deal so it's a race against time
- 0% interest rates creating economies in which “you’d be crazy not to grab as much land as you can”
- Skill issue or will issue to listen to someone with the skill

## Approaches
- Do one thing at a time
- Hire people who’ve actually scaled without killing the company, and listen to them tell you to do one thing at a time

Expanded everywhere

## Description
- Shit happens; if your plan was to figure it out live, that’s not a plan

## Disproof
- Incident Response Plans that are actually followed, someone who’s responsible at any given point (and everyone else knowing who that person is), dedicated comms, post-mortems, etc

## Consequences
- Wasted employee time
- Extremely variable resolution times
- Destruction of user trust
- Mis-managed ad-libbed public response
- Overall reputational dumpster fire
- Get outcompeted and die

## Causes
- Unless you’re genuinely useless, someone at one time probably tried to create a process. That process is likely to be:
    a) evolved, sometimes in over-corrected response to a prior disaster
    b) poorly linked up between infrastructure, technical and non-technical support teams
    c) overlapping or gappy
- Furthermore, lack of discipline in a crisis will tend to create a divergent feedback loop - the headless chickens run into electric fences, overload them and cascade taking down the grid
- In certain corporate cases, extreme cognitive dissonance or overconfidence in one’s own preventative measures prevents them from solidifying these measures.

## Approaches
- Again, if you haven’t heard of SRE start there
- If you’re finding out about things breaking from twitter/x/y/z, you’re already in bad shape
- If you’re finding out about things breaking from your monitoring but then scratching your head about who to DM to start fixing things or having a everything-is-on-fire megathread on the general channel... yeah
- If you don’t have user support with clear rules of escalation, and/or every case of user-side breakage or user error gets bounced around until it becomes a ‘bug’ with no reproducability steps, that’s also a problem

Forgot that things still break

## Description
- You somehow expect multiple people in (hopefully) multiple departments to spontaneously self-organise into a rube goldberg machine that gets the product marketed, sold, billed, paid for, supported…

## Disproof
- Some documents detailing what happens when integration tests succeed 

## Consequences
- In addition to the usual consequences \(you die\), it also has a wonderful mid-term effect of destroying goodwill across the company as one team inevitably pays for another team's fuckups
- Or, some teams might actually try to spontaneously self-organise in response to pain
    - The problem is that like neurons, teams that fire together wire together and this might not be the best thing
    - Evolution may cobble together something that works but lord will it be inefficient and have nasty externalities
    - Be inefficient enough and someone else eats your lunch

## Causes
- Usually results when the founding team could handle everything until it couldn’t, then either hired people and prayed, or just sucked at organisational design
- Can also crop up in orgs with multiple operational teams, no clear leader and a lot of feudalism
- This is effectively a superset of 'hope as a strategy' that relies on multiple departments to remember to both do their thing and communicate their thing, assuming they even have enough information to do so in the first place

## Approaches
- If you’ve not already mapped everything out, start there. Then get everyone on board

Forgot to operationalise

## Description
- If you work in tech and the concepts of SRE, CI/CD or monitoring are news to you, evaluate your life choices

## Disproof
- A monitoring dashboard and alerts

## Consequences
- Either it catches fire the moment you deploy, in which case you’re just bleeding a bit of opportunity
- Or it gets popular and then catches fire just as you’re really raking it in:
    - Then you’ve got pissed off users, who may flame you online, and probably won’t come back,
    - You’ve got to start from scratch assuming you’ve even got enough of an untainted demographic left
- Either way, get ready for a divergent feedback system of overcorrection, destruction of trust within the product team itself, and generally bad consequences of customer goodwill destruction, time lost and existential threats

## Causes
- Sometimes, nobody has quantified the costs and consequences of an outage
- As companies are not static things that don't develop over time, chances are what happened was:
    - A 'no-fun stickler' in engineering was extremely disagreeable about not anticipating scale or reliability issues
    - A 'go-getter' in middle management smugly won the 'premature optimization' argument
    - Face was lost, exasperation and emotional fatigue means the topic is never brought up again
    - Time passes, people forget, it really does become the time for that previously pre-mature optimization
    - Things blow up, the stickler's probably already left and if not says "I told you so."
    - The team over-corrects, over-engineers the shit out of the next thing
    - Business gets pissed off that there's no value being generated and the go-getter squashes it again.
    - And so the tables turn.
- And sometimes it really is just a skill issue

## Approaches
- Ensure you’ve got good engineers and ensure one of them is in the room when someone’s deciding what to do with their time. If they are good engineers, they’ll insist on making sure it won’t fall over
- If you have a dev/SRE split, then ensure the latter is around when making decisions
- To ensure everyone is on the same page, calculate and publicise the cost of an outage

Forgot to productionise

## Description
- Delivery starts with awareness and is only done when the user retains (ideally refers), so you better have a plan for _everything_ that leads to that point

## Disproof
- A centrally verifiable map of the complete user journey _with direct responsibility assigned to every step_

## Consequences
- There are myriad interactions with the user, and no single team can handle everything. Effort will either:
    - Get duplicated / move out of sync in silos, only to get lobbed over the wall for someone else to scramble on
    - Fall between responsibilities and not actually happen
- You won’t have any idea of compound impacts and whether something is feeding through / working
    - You burn money and time on things that don’t work
- Best case you waste weels, worst case you damage your reputation, either way you stand to lose customers and money

## Causes
- Silo’d teams with different incentives all pulling in their own directions
    - Typically a failure of organisational design
    - Can also arise due to politics and feudalism
- The lack of anyone suitably motivated to fix it from within a given department
- And in all cases, whenever a process only exists in people’s heads, you stand to have have as many processes as heads

## Approaches
- True Funnels represent the COMPLETE user journey. They start with how your user hears about the product, and ends up all the way past acquiring, using, getting value from it, all the way out to convincing someone else to use it
- Write it down, agree it, and revisit it in contact with reality

Forgot where it starts and ends

## Description
- Everything has gone ‘right’ - bugs are caught and fixed, all lines of support are operating smoothly; the ‘problem’ is that it’s just not doing it for some users

## Disproof
- You’ve got a PR and social listening strateg(y/ist)

## Consequences
- More than one startup has found themselves in a situation where a co-founder gets locked in a flame war with some pissed off user on twitter
- It should be hopefully obvious that letting the unplanned happen in public discourse on the open internet means that one misstep will blow up in one’s face
- In short, you will lose customers not only over the problem itself, but compounded as your cack-handed response itself becomes the object of a witch hunt
- If you time things well, you could just murder your company on the cusp of traction.
    - Think about it, you’re iterating, things are starting to resonate. People are NOTICING you
    - Then you bungle a response to someone who you might have shifted the feature set away from serving and lo behold, a dumpster fire as you insult their grandmother

## Causes
- Not having a strategy for:
    - Figuring out why users are dissatisfied
    - Figuring out which ones should be addressed and which ones are not actually legitimate
    - Resolving the dissatisfaction in such a way that leaves the user an even bigger supporter of the product and the brand
- Sometimes it’s a user/value mismatch and you shouldn’t have been serving them in the first place, and it was just bad luck they picked up the product

## Approaches
- This really depends on just how aggrieved, motivated and connected the user is
    - You should never really be in the business of ignoring genuine dissatisfaction
    - Especially in cases where reputation is at stake
    - Unless you calculate that the pruning effect of that user’s damaging your reputation with mismatched allows you to focus more
    - Do this maths very carefully
- If the grievance is legitimate, the user is motivated and connected, the impact could be as little as losing some users and as much as losing most users
    - Either way, don’t not consider it, and definitely don’t go to war with them
    - It doesn't come down to who was right - it comes down to how it looks
- Also, get media training

No plan for dissatisfied users

## Description
- You say all the right things in the wrong room

## Disproof
- A scrap of evidence that identifies key channels, outlets or forums that your (very clearly identified) customer segment prefers, authorities they trust, or places they literally go drinking.

## Consequences
- The scatter-gun approach may work long enough for you to be outcompeted by someone who spends their growth budget only on effective channels
- You most likely overspend, or misdiagnose the problem and burn more money on engineering. Lose money, people and the business
- Promoting your product in the wrong channels may actually harm your perception if your users are vicious enough or you've made it part of your personality to be 'hip'


## Causes
- Almost 100% a skill issue
- But can also be due to some biases; “I’m in charge around here! AOL ads worked great for us in 2000!”
- Usually due to siloed understanding of customers
    - Very common in places where the people responsible for researching the customer are bunkered out waaaay behind those building for the customer, and very very far away from those selling to the customer

## Approaches
- It’s never just what someone needs to hear; it’s also how, when and from who
- Each user has an optimal way of being reached, determined by the dynamics of their situations or markets. You won’t know this without asking questions like:
    - What do they read?
    - Where is their watering hole?
    - How do they interact?
    - Who or what do they trust?
    - What point is it relevant to introduce your product?
- Critically ensure that everyone in the business is formally sharing their understanding of the customers and updating constantly based on real-world interaction

Not finding customers where they are

## Description
- The problem with your users is that they ‘just don’t get it’? That actually sounds like a you problem

## Disproof
- A document that all teams have actually read which describes psychologically why customers value your product and how they become aware of that fact

## Consequences
- Best case scenario, all that time and effort you sank into doing everything else right goes to waste
- Teams become unsure whether they are actually targeting the correctly customers wrongly, or the wrong customers correctly and can lead to even worse overcorrections
- Embarrassing doubling down on marketing/communications that go from tone-deaf to cringe and irritating
- You get buried under competition with a bad product that shouts better, the team gripes about fairness all the way to the job centre

## Causes
- Hot take: product teams attract people who consider themselves builders/makers/creators. Tends to lead to such groupthink as:
    - "The product should be so good it sells itself!"
    - "If it’s not popular it’s because we just need to keep improving it until everyone recommends it!"
    - "Talking about your product is gross and dishonest, we’re cooler than that!"
- Sometimes the existence of a particularity opinionated standalone creative/marketing team creates a learned helplessness. Positioning thinking is then not done by the people who are supposed to care about the user
- Sometimes, people even do think about the positioning. The problem is - they don’t talk to each other
    - You may see different teams talking about the product in entirely different ways which becomes especially confusing in longitudinal situations
    - You marketed it one way, sold it second, billed it a third and supported it a fourth
- Moderate success and complacency that doesn't hold up in a shifting market

## Approaches
- There are volumes written about the practicalities of this by some of the greatest minds in advertising. Go read one - I recommend Sutherland's Alchemy
- If bad product management is the failure to identify and build for value, bad product positioning is to fail to connect users to the value, effectively snatching defeat from the jaws of victory
    - More structurally, if you’re not engaging with how your product is making your user feel, you might as well just be banging rocks together
- If the organisation of your company is preventing this thinking from a) happening and b) being joined up, work on that first

Not trying to resonate

## Description
- Skipping translations or how to use something in the name of speed is a great way to reduce speed to 0

## Disproof
- As many customers as you care to serve can use the product and read the labels

## Consequences
- Lose time you never really had catching up 
- Destroy trust
- In the case of documentation, if the product is not very useable you also probably vastly underestimated your suport costs

## Causes
- Someone forgot that multiple work streams could happen at once
- Or, because things like documentation or UX labels are dependent on the product itself, time for working on these things is somewhere between:
    - A) Right when you start off, earning you the pain of fixing and updating documents and labels as you go along and iterate; or
    - B) Once you’re in production and dealing with pain and representational damage for these things not being in place
- Often, teams use the excuse of (A) to wait until (B), which again just results in all the hard work of doing everything else on time and in sync being wasted as you pay the scramble price or pay the user happiness price

## Approaches
- Learn to coordinate, ideally through automation

Shipped without docs or i18n

## Description
- Shipping early and often doesn’t have to mean shipping a potentially un-good thing to everyone and poisoning the well

## Disproof
- Err, demonstrably not launching to everyone?

## Consequences
- You launch something untested and find out a whole bunch of ugly that you could have done with five hallway testers
- It costs you an entire consumer cohort / demographic who’ve written you off as a bunch of incompetents (because you are)
- Support gets overwhelmed with a spike across 100% of the user base, resolution times skyrocket and you look doubly bad
- Hey, you might even get cancelled!

## Causes
- Pressure to move fast
- Unwillingness to invest in tools/infrastructure to do sane things like a/b testing and feature flagging
- Unwillingness to invest in tools/infrastructure to understand what’s working without picking up the phone and calling random customers
- Planning by people who think you’ll magically get it right, so schedule a big public launch for the day the engineers submit their first pull request
- When product leadership themselves are off fighting fires instead of managing and aligning expectations

## Approaches
- Usually a stakeholder education issue
- If everyone knows the score and there’s still pressure to yeet it at everyone as fast as possible, just do the maths of failure again

Straight to GA

## Description
- GTM teams work their hardest, learning from everything they’ve done before but are fighting an uphill battle from the last flamewar a cofounder got into on twitter (yes I mention this twice)

## Disproof
- Evidence of a listening strategy

## Consequences
- Mostly an efficiency loss, but when margins are thin could be fatal
- Damaging morale of teams that didn’t ‘do anything wrong’ and losing good people
- If doubled down on or overcorrected for, can kick off a reputational deathspiral
- Often comorbid with a similar approach in product design so worth being very cautious of; if you’re failing to understand customers at that level it’s just a matter of time

## Causes
- Almost always happens in cases where the company is more interested in speaking at, than listening to,the customer
- Can either be a result of success through luck, or when some ‘visionary’ thinks they’re in a faster horses situtation
- Some form of time pressure or resource misallocation prevents this happening bottom-up; these workflows aren't free and only work at scale with tooling
- In sadder cases, some teams are very interested in listening to the customer - they just have no influence on the teams doing the talking

## Approaches
- Beyond beginning to care / ask what customers think about the product, approach will be highly industry-dependent
- Identify and resolve sources of resistance, as time and effort is rarely the only issue

Forgot reputation and slander

## Description
- A startling amount of people are simply delighted when they acquire a user at all, or do so for 5% cheaper than they did last month (at least they’re trying)

## Disproof
- A positive cashflow or a path to it

## Consequences
- Problem 0: ROAS not being considered at all
    - You definitely will spend more money than you need, possibly more than you can afford
    - It is very possible to start acquiring customers for more than their gross revenue
- Problem 1: Calculations are woefully incomplete
    - You probably forgot it costs money to operate customers, approved an acquisition strategy with hair-thin CAC-LTV and now can’t get rid of them whilst they rack up support or server costs
    - This is often the way that scaling companies are killed

## Causes
- Very likely because acquisition costs and operation costs are distributed across multiple reporting lines (which already reduces opportunities to consolidate and optimise costs)
- Further exacerbated by poor alignment in departmental objectives
- Co-morbid with poor organisational information discipline

## Approaches
- If nobody is doing joined-up thinking, start there
- If nobody is directly responsible after the thinking has been done, continue there
- You will probably have to tackle the failures in organisational design and incentives for any lasting improvements

Gappy customer economics

## Description
- Someone thought enough to go wide with this thing, and has lit up social, paid, referral, even paid some students to twirl signboards. Problem is, like Brian Johnson, they’ve done the most statistically useless thing: sample size of one, a bazillion simultaneous interventions, and no clue which one(s) is doing the heavy lifting

## Disproof
- Hard numbers isolating the most successful channel path and a rationale to back it up

## Consequences
- Problem 1: confidence in the wrong thing
    - You think you’ve found ‘the’ channel because that’s where you convert from
    - You double down on it only for it to flop because they haven’t had the 5 previous touches across paid, search, etc.
    - You waste money trying to score on the first date with cold users who get grossed out and you burn your general reputation
- Problem 2: confidence in no thing
    - Your only followup move is to attempt to get lighting to strike twice by going full macross-missile-massacre on it
    - You burn money that could be used to make the product better or (gasp) profit and build some cash position to insulate against future stupidity
    - Your acquisition costs grows linearly, but the marginal value of your customers is likely to decrease logarithmically, meaning at some point this makes negative money
    - Firing blind whilst money gun marketing has a 50/50 chance of you running out of ammo before you bring in enough customers to reload

## Causes
- Especially common where several teams and external agencies are responsible for customer acquisition and there is no joined up thinking between the social and the paid team, for example
- Occasional skill issue
- Making it some people’s sole jobs to spend money and not aligning their outcomes with the rest of the company
- The user’s journey from first contact to conversion can take up to 50 touches - most companies don't track this

## Approaches
- Consider an ever so slight bureaucratic burden of asking people to write down _why_ they think the sign twirling is going to be more successful than the NFT campaign or billboard on the interstate, and by _how much_.

No idea why it’s performing

## Description
- You have no idea why people like it, but it do be shiftin’

## Disproof
- Large-scale post-acquisition data on what the product _means_ to the user and how they learned that meaning

## Consequences
- Success without understanding is luck, and luck runs out
- Despite there being no immediate risks, this creates hubris/complacency
- You won’t understand your customer better and miss opportunities to better serve them or solve other problems for them
- You won’t develop the skills to position the next product, over-reach and die
- The next shiny thing comes along and you lose your users

## Causes
- No culture of understanding what drove success
- Satisficing biases - you think you know why people like it, read a few happy tweets from a fraction of your user base and don’t question it further
- “Of course it’s awesome, we made it”
- Time pressure to move on to the next one

## Approaches
- Frankly, it’s very hard to fight a rising market and it might be better conserving strength to act when things start to go wrong

Not asking why it resonates

## Description
- Commercial teams have spent a weeklong yoga retreat stripping down every tiny detail of what worked and didn’t work over last quarter’s marketing push. Product teams never hear of it

## Disproof
- Regular cross-functional G2M evaluations or evidently disseminated information

## Consequences
- People capable of improving both product and positioning are not involved in improving either CAC or LTV
    - Burning both money and opportunity, possibly at the cost of being out-competed

## Causes
- Comes from product teams being ‘kept in their lane’ away from anything financial
    - Creating learned helplessness in specialists who could really use the thought exercise
    - Reinforced by “well the lights are still on so no point bothering to ask”
    - Exacerbated by poor product leadership which fails to impress upon specialists the importance of having a salary the next month
- Most often results from ideological divides and bad blood between the builders and the sellers, and their leadership not bothering to fix it
    - With enough mavericks commiting to custom builds and deadlines to get the deal done, and product people will freeze them out

## Approaches
- Usually, the pull will not come from the commercial teams so push needs to come from those responsible and diplomatic enough on the product team
    - Top-down ‘now get along!’ rescue interventions rarely work or last; you’re better off coaching
    - Generally, cooperation needs to be suggested with charm and mutual benefit rather than finger-pointing and alarmism, but a healthy dose of consequences of failure never hurts

Siloed evaluation

## Description
- You pretend that you only have one user type and that there’s a strictly linear value proposition that was met for everyone. You try to do more of the same, and it’s shocked pikachu faces all around as people respond very differently

## Disproof
- Name two customer types and show me their journeys

## Consequences
- You assume you'll be able to repeat success but your next cohort contains a different blend of users lacking context/capability and you crash
- You waste budget targeting the wrong people or informing users who won't benefit
- Eroding confidence starts to paralyse decision-making ability, good people leave and death spirals begin

## Causes
- Surprisingly, happens when companies try to be religious about their users - cultish devotion to ‘the user’ means you don’t talk about ‘which’ user
- When some genius tries for an MAU-first-monetise-later play...in the 2020s
- In cases where everyone is actually trying to do this, under-investment in tools to segment users at scale results in a thumb-suck with more steps

## Approaches
- Once you get past any performative user-centrism, solid hours put into user research with a quantitative bent
- Realistically, no company is going to have its user focus down pat and greed/lack-of-discipline will generally result in targeting of multiple adjacent types knowingly or not

Assuming it works the same for all users

## Description
- Pretending it didn’t go wrong might protect the vibes or save someone a bollocking but it will kill you in the long run

## Disproof
- Frequent blame-free postmortems with actioned findings

## Consequences
- Compound ostriching where the teams launch dud after dud, run out of money and kill the company
- Leadership being told that everything is fine, not verifying, and planning even more disastrous expansions

## Causes
- Nearly 100% due to environmental toxicity:
    - Failure is highly punished, leading to an unwillingness to report it for fear of blame; or
    - Company is toxically positive and any discussion of failure gets gaslit into silence; or
    - Failure response is highly performative and results in a lot of public consultations, cross functional inquiries and all-hand meetings that may even dissect the failure in detail without any action
- When it _is_ a skill issue, is when you’re so focused on working out what went wrong to realise you’re supposed to do something about it

## Approaches
- If failures are not explicitly framed as a valid and necessary means of improvement you will have very little success
- Work to get everyone past blame, which involves creating psychological safety if done from the top. Remember your equity depends on this.
- If safety is being created from the middle, takes courage from the ones creating it as they’ll be convincing their superiors and peers to try it out and taking the blame if it fails

Failure to address failure

## Description
- If something grows as it’s used, make sure you know in which direction

## Disproof
- Documented understanding of the lifecycle of your product portfolio

## Consequences
- Betting on the wrong thing because initial metrics are promising:
    - The long-term use of a product changes and could degrade its effectiveness
    - Some content-based products work great when there’s a low quantity of content, but become entirely unworkable with noise
    - Or when the work a user generates becomes unworkable, e.g. notion or to-do lists
    - You planned the next year assuming you’d retain but everyone leaves as stuff gets clogged up. You’re stretched thin and die
- Abandoning real winners too early:
    - Some products only become successful when used often, or when network effects take hold, or when users generate enough content, or when marketplaces get populated
    - Habit trackers, anything reliant on showing users longitudinal improvements
    - Anything requiring internalised skill to use well (despite what some artistes believe, it’s OK for some things to not be easy to use on day one, especially if the user’s motivations for getting good are high and the cost of dumbing the product down is greater than making it complex)
    - You pivot into something less valuable and risk the company
    - Possibly acquiring the wrong types of users that are not valuable and costly to serve, stretching the org and potentially killing it

## Causes
- Genuine skill issues in joined-up long-term thinking and cohort analysis
- Measurement tool underinvestment due to misguided cost-saving
- Time pressure exacerbating blindness to the blindness


## Approaches
- The point is not to always wait 6 months to see if your product is working, but to stop and consider what kind of structural situation you’re in

Forgot about cumulative usage

## Description
- Why are you still just tracking MAU?

## Disproof
- Numbers that are connected all the way through user value to your continued existence 

## Consequences
- Your solution ends up looking like it’s working when it’s really not
- After a great amount of effort and money to acquire them, you start bleeding customers. 
- You probably throw a bunch of money at re-acquiring these “warm inactive leads” (generally they cost 3x to reacquire) instead of fixing the problem in the first place
- Each attempt to move the wrong number gets more and more wrong. Eventually, the music stops and you never realised it was a funeral dirge - you were too busy trying to polka

## Causes
- Some smartass got the “you can’t improve what you don’t measure” part right, and entirely missed the part where measuring the wrong thing leads to improving the wrong thing
- A new leadership hire will assert dominance by demanding quantified r-e-s-u-l-t-s and find themselves getting d-e-f-l-e-c-t-e-d by big numbers that look good
- Some teams just want to feel good about a number they can make go up quickly instead of a number that matters, and in a culture that’s not critical about numbers everyone else buys the hype
- And sometimes, nobody realises that metrics themselves abstract away important information - "the numbers made me do it" (see Sutherland’s talk on this)
- Otherwise it can just be that you failed to create joined-up thinking across the organisation

## Approaches
- Ask people what the point of the product is and see if anyone says “solve it so good that each successive customer gets cheaper to acquire”
- Try a strategy different from “throw more VC money at it”
- Try to understand why you're measuring something

Measured the wrong thing

## Description
- We listened, here's our improved all-steel umbrella, now impervious to 6-inch hailstones based on user feedback! Only 25 pounds!

## Disproof
- Quantification how much of your core user group actually holds any given opinion

## Consequences
- You improve for something that’s really not important
    -  You burn time, money and possibly drive the majority of users away
    - Congratulations, you played yourself

## Causes
- In B2B situations, whoever kicks their account manager the hardest will get them to shout the loudest, with predictable outcomes
- You may have hired people who look really good when it comes to designing and building, but actually haven’t been around for the full product lifecycle and don’t really know what to do at this point
    - Leadership roles self-select for serial job hoppers with nothing to their name but a half-dozen shipments they didn’t stick around to evaluate/improve
- Else, you created unnecessary time pressure that will come back to bite you; rushed evaluation is on par with no evaluation
- Some more banal causes also include; insufficient segmentation, unqualified focus on quantified data, confirmation biases and unspecific feedback collection methods

## Approaches
- If users tell you something’s not working for them, it’s a good idea to listen
- If users tell you what they want it to do, it’s a good idea to take it under advisement and then actually figure out what the problem with the solution was
- Either way, create conditions where everyone understands that feedback is successfully implemented when it produces results you want, not when it passes unit tests

Overgeneralised feedback

## Description
- Externalities are a bitch and sometimes you reap the whirlwind

## Disproof
- Evidence of problem resolution instead of relocation

## Consequences
- In B2B, _someone_ always pays for the externalities with labour
    - If that someone is your operational teams because you sell a solved problem, work will probably land on functions that are not designed for it and kill them
    - If that someone is another department in your customer because you sell a tool, you might end up without a customer
- When the solution creates actual social/environmental externalities in the part of the world you’re _not_ monitoring because they’re not your target demographic, this tends to blindside you
- And can cost everything from customers to the business

## Causes
- Typically, greed is to blame here but skill issues can also cause this especially when expanding into a new domain
- Especially common in marketplaces when launching into adjacent categories and underestimate the guiderails and gubbins that go around the actual transaction
- Usually, someone will have spotted this and been ignored
- Sometimes can genuinely be caused by incomplete product thinking or launching too early

## Approaches
- Start by being realistic with the product that was too good to be true; because that was never sustainable in the first place unless you planned to pump and dump
- From there, work out and accept the costs of building it right; hopefully you will still have a viable business

Shifted a problem elsewhere

## Description
- Your product tests exactly one hypothesis. Making needless assumptions just compounds your chance of failure before the real exam actually begins.

### Disproof
- Your problem statement has exactly 1 \(one\) thing that you need to fuck around and find out about, and it is explicitly defined as your product hypothesis

## Consequences
- You become that company known for torching millions to build something they could have found out wouldn't work/sell just by asking a few passerby

## Causes
- Usually, a combination of excitement and a damn-the-torpedoes attitude, exacerbated by people trying to look good
- It's rare to be completely oblivious. Normally, the excitement to build runs away from you _juuust_ long enough that when you come to your senses, sunk-cost fallacy kicks in, and "the only way out is through", etc.
- Unfortunately, there is a very real fear of being disagreeable / being blamed for wasting time that somehow leads to people doubling down and wasting more time

## Approaches
- Look at your problem statement. If _any_ assumptions can be tested without building the entire product first, it is your duty to validate those to the best of cost effectiveness
- Take a good hard look at what remains and work out how screwed you’d be if none of your assumptions turned out to be the case, and decide if you’ve got the stones to roll the dice
- That’s not to say don’t do it, as you’ll find out a lot by being in contact with reality. This might provide workable opportunities, but either have a plan or be prepared to think very fast and definitely have some budget
- Practice...sigh...awareness. Have something built in to your way of working that structurally forces you to come up for air

Assumed the testable

## Description
- Through diligent by-the-book user thinking that agile coach told you to do, you've concluded that everyone has the problem and your addressable market is the whole industry/world

## Disproof
- You have specific personas and a description of who’s not your customer

## Consequences
- You might think you’re designing for a safe average but in reality you’ll be making siloed sub-optimisations for contradictory requirements across multiple target demographics, resulting in an incoherant dumpster fire that nobody will buy. No revenue, no customers, no exit
- Should you ever make it to launch, your messaging, distribution, operationalisation and pretty much everything else will be as incoherent, you’ll torch money and die

## Causes
- Pressure to broaden the scope and 'expand that TAM', buddy
- Laziness on the behalf of product and design in particular, or more likely a fear of pushing back
- Prior success and the hubris that makes you think that one-to-many is easy because you did zero-to-one

## Approaches
- The product team needs to drive, not receive, the target market, including calculating viability (with help)
- If the pressure is coming from outside the product team, find out what that pressure wants and demonstrate how doing this will not get them it

Built for Everybody

## Description
- You fall in love with a cool problem that requires building cool tech to solve. Unfortunately, nobody needed it and you don't have a business, you have a science fair project

## Disproof
- Fill in the blanks “[    ] people are unable to do [    ] within [    ] constraints, are willing to pay / exchange value to do so, and we can reach them through [  ]”

## Consequences
- You’ve set yourself up as a for-profit product business, make no product, no profit, and go out of business
- The speed of this is usually attenuated by burning money from elsewhere
- At best you've wasted a bit of time and spent your savings
- At worst you've wasted a lot of time, burnt someone else's money and will forever be known as “those nerds who have no idea about business”. Non-American investors will probably not give you a second chance, even if you 'learned your lesson'


## Causes
- Mostly, people find a new technology, thinks “this could do wonders!” and fail to specify those wonders, or work backward to someone who actually needs said wonders
- When product teams that are too autonomous chase the shiny over the valuable
- When a nontechnical PM is too intimidated to do their job and represent the customer and the business to the product team
- When customers give you a solution, and instead of investigating what problem it solves you build it
- Chasing trends

## Approaches
- If you don’t have any constraints on your time and money, this might not be an issue, but most of us do somewhat. If you’re honest with yourself, do fundamental science and just throw it at enough things to see what sticks, no problem
- If you’ve started at a technology (which remember, is the answer - not the question), go be an enabling technology provider and partner with someone who actually has a problem to solve, but don’t trick yourself into thinking you’re building a product company and get the rest of the execution wrong
- Gently remind people that if we spend money to not make money then there’s eventually no money and no people

No user, no value

## Description
- You can’t tell if it’s working if you don’t know what working is

## Disproof
- A quantified, time-bound and verifiable target, hopefully in some way remotely related to the company mission

## Consequences
- General product x operational chaos as expectations are mismatched, deadlines are nonexistent or misintepreted, and goodwill is destroyed
    - As a general rule of multi-team companies: if communication fails it does not self-restore
    - This tends to create feedback loops until the business grinds to a halt, gets outcompeted, and dies
- Keep groping around in the dark long enough, you'll cut your hands and bleed out

## Causes
- Happens depressingly often when you disconnect product teams from the notions of users and value, and toss them random things to build
- Not usually something that the product teams directly avoid, but are rather kept away from
- Sometimes it can just be a skill issue

## Approaches
- This obviously propagates to the evaluation stage but should come early and be reviewed often
- By construction you can’t actually know exactly what success looks like, but by defining _what_ you think it is and carefully updating _where_ you think it is as you gain data, you can error-correct yourself and keep moving towards it

Forgot to define success

## Description
- You’re building a faster horse

## Disproof
- Document stating what problem the competition is solving - not what it's selling - and why your solution will be more successful

## Consequences
- Focusing on what the incumbent has already made will blind you to the problem space, and then you’re just trying to beat them at their own game
- Very little hope at providing more value exists unless there’s a direct cost undercutting or it's dramatically easier to acquire/use, and even then you are still fighting the ever-present switching costs and the "nobody ever got fired for buying IBM"
- By construction, an existing solution was built on older paradigms and technologies, and due to the inertia of its technical debt, will possibly itself not be addressing problems only addressable by today’s technology
- You effectively throw away the clean slate advantage and fight someone else’s first mover advantage
- The only exception is if you're very fast, very rich, very connected or all of the above

## Causes
- Surprisingly common mistake where the problem definition is skipped altogether because someone gets obsessed at 'beating' the leader
- Lack of originality, or more likely time granted to the product team to be original
- Someone used the D-word and everyone took ‘disrupt’ to mean ‘duplicate’
- Sometimes, product teams can misinterpret signals from leadership and not question it further out of fear - at this point you have larger cultural problems

## Approaches
- Existing solutions are fine as signals that the problem exists, and it is very fine to use their failings to understand the problem better, but you really have to look in the right direction

Incremented on incumbent

## Description
- Nobody is sure what’s going to happen by what point

## Disproof
- A common, mutually verified of what is being solved by when

## Consequences 
- Some poor account manager might see an early testing build and tells a customer it's shipping ASAP and be left sweating as bug after bug gets found in QA
- Marketing can jump the gun and announce a launch date well before something is ready for GA
- You multiply the drama when the company is actually misaligned on how _much_ of the solution is going to be out by when - product is proud for launching something simple, loveable and complete to only get screamed at for not shipping an enterprise grade solution on day one
- Generally, market and customer trust gets destroyed and once a cohort is lost, it is lost

## Causes
- Usually starts from not having ‘done’ defined
- This tends to be worst in B2B businesses with high amounts of nontechnical staff, who tend to assume building stuff is an atomic process that just completes the moment code gets checked in
- As ever, silo’d teams with poor communication skills make it worse

## Approaches
- Educate everyone on the phases of product development for starters, including the notion of testing and iteration. Drill them on the differences between code completion, review, technical QA, acceptance testing, A/B, controlled availability, general availability
- Be explicit about what you aim to achieve by when

Misaligned on Time

## Description
- You’ve got a user. You even know what situations they’ve got a problem in. And theeeeen you’ve stopped. Not thought about what they can and can’t do. What constraints are real and which are imagined.

## Disproof
- Widely agreed docs stating which constraints impact your user’s ability to make decisions, that demonstrably informs design constraints at solution stage.

## Consequences
- All user problems arise from the capability gap described by what they Can't Not Do and what they Can't Do
    - In other words, the gap of perceived capabilities/resources vs a task that is important to them
    - I say Can’t Not Do because it's often driven by an unwillingness to accept the consequences of not doing (miss social events or get fired etc.), rather than anything they actually must do
    - The user's understanding of their own constraints (capability/compliance) is often wrong, and in some cases (B2C) so is their understanding of what they want to do
    - If you don't even have these constraints in mind, you overextend building something that users can't even use due to being 'blocked' from accessing value, run out of money and die
- Even if you understand the constraints as your users do, you miss massive opportunities in getting users to relax imagined constraints (the ones with non-occurring bad consequences)
    - Any solution you build is going to be suboptimal
    - You might succeed mildly, get complacent, and get rekt by someone who's figured out how to serve the same users better or cheaper because they dug deeper
    - Users churn, revenue drops, you burn through your runway, and you die

## Causes
- Most teams simply don't recognise that there are first-order constraints that drive second-order, imagined constraints
    - As an aside: this is the same reason why these teams and their leaders are not fixing their own companies. They are trapped in the imagined constraints and compulsions.
- Largely because this type of thinking only occurs when workloads have been balanced correctly so that somebody capable is doing proper thinking, yet most product teams are:
    - under-resourced
    - doing the wrong work (like a VP's pet project)
    - wasting their time doing someone else’s work (like explaining shit that is in the docs)

## Approaches
- Create the thinking time and defend it like your equity depends on it
- Make it someone’s responsibility with a deliverable artefact
- If struggling for buy-in, demonstrate what happens if this doesn't, get agreement on it

Missed user constraints

## Description
- You found a problem! Problem is, it’s not the real problem and you’re treating the symptom not the cause. You’re also missing the structural forces and 4 comorbidities that are interacting with each other

## Disproof
- Rigorous, peer reviewed root cause analysis is usually a decent indicator

## Consequences
- Incomplete problems lead to incomplete solutions
- And whilst it’s fine to sometimes minimally viable, partial solutions, you need to contact value early and often or else you’re going to have to keep building until you do
- You may end up trying to remove Chesterton's fence and create more problems by solving the wrong one
- If you’re not very clear on the problem space, you might have a big lag in discovering how to take your incomplete solution towards completion
- You use your 'trust me bro' card, the bandwagon effect makes it snowball
    - You build, operationalise and try to sell a solution to a problem you’re convinced is The One only to find it Ain’t It
    - Months and millions go up in smoke

## Causes
- Usually a combination of noise from other stakeholders about this definitely being the problem
- And / or the entire phase is being rushed and nobody is checking each other's work
- This leads to satisficing / explanation bias where the plausibility of the reason you find means you stop looking for a real reason, or as I call it - problematic lamp shading

## Approaches
- Asking the question and answering honestly
- Most of the time this is entirely within the product team's ability to resolve. It just takes awareness and courage

Problem blinded

## Description
- You’ve shot so far past not copying the competition that you’re not aware of them at all

## Disproof
- Being demonstrably the only company solving a problem as evidenced by the problem only being solved through duct-tape and excel spreadsheets

## Consequences
- At best: wasting time re-inventing wheels when you could be working on the internal combustion engine in a horse-and-buggy world
- At worst: missing a non-product reason why your competitor has an unfair advantage and will be able to keep its moat. This can lead to an extremely valuable, operationalised product that doesn’t have a hope in hell of succeeding

## Causes
- Can genuinely happen due to everyone being too busy making the thing to look around
- The hubris of exceptionalism: an honest belief you have no competition - there are very few ‘categories of one’ despite what you’ll hear on a pitch day. Beware Macduff.
- Problems as they are currently being solved functionally define who is your competitor or not, not whether anyone else is using crypto to do something a database could do perfectly well

## Approaches
- Compare problems to problems not solutions to solutions. News of a funding round or two usually helps to snap you out of it
- It is also worth studying how your competitors have positioned and operationalised their products, and profiting from their mistakes

Denied competition

## Description
- The maths isn’t wrong or missing altogether, it’s just incomplete. You failed to account for a major factor impacting this problem

## Disproof
- Some kind of product lifecycle analysis with clear drivers that are testable

## Consequences
- Failing to forecast will often result in greenlighting an on-paper profitable product. Said product will massively under-perform or even cost to too much to run, and generally sunk cost fallacy leads to ‘sticking it out’ instead of recognising it for the lost cause it always was
- If you’ve over-indexed on the product being successful, you’ll probably be spending more and this will definitely lead to some very unhappy corrections, usually in the form of jobs

## Causes
- Generally, because anyone looking at costs top-down misses granularity and those looking at costs bottom-up miss context and interaction effects
- People most often miss longitudinal things -
    - How do the financial dynamics of solving this problem evolve over time?
    - Who else will come into play next year?
    - What happens if you have to educate the customer?
    - What happens if customers don’t retain?
    - Is it possible to oversaturate / are you assuming demand is infinitely scalable? (cough cough Disney)
- Hidden costs in customers:
    - Acquisition
    - Support
    - Charge backs
- Hidden costs in operations:
    - Any variable cost as-a-Service infrastructure that doesn’t 1:1 correlate with revenue (e.g. search indexing) in a business model where revenue is fixed recurring
    - Maintenance
    - Retraining

## Approaches
- If the product team is doing the maths, get them help
- If the product team isn’t doing the maths, get them involved
- Ensure you have enumerated your cost and revenue sources

Didn’t complete the maths

## Description
- We did all our homework and are ready to build! Wait, why is everyone screaming at us

## Disproof
- You’ve actually run this by everyone

## Consequences
- If something is built without considering the needs of those bringing it to market and those keeping it running, it has a high chance of not making it to market, or running
- If the product even makes it past QA, it, will be received as well as a live grenade
- You’re left with the choice of slamming on the breaks, or risking negative net revenue, criminal liability, reputation damage or worse 

## Causes
- This is generally symptomatic of poor organisational design and poor communication design, coupled with poor alignment effort on all parts
- Information is not being automatically propagated, and if that information causes concern for some stakeholders they don’t action it
- Or, some genius tries blasting all information at everyone, and everyone tunes it
- The lifecycle usually goes thus:
    - In the early days, everyone was in the same room. Everyone knew what they needed
    - Then you grew, and the amount of information did too. People structurally couldn’t know everything, and nobody taught them how to share relevant information
    - The teams became bigger and more isolated until someone said “Enough! We need alignment meetings, talk to each other”
    - These eventually got bloated/useless because the people running those meetings were too busy to tune them or spread information to their teams
    - Everyone throws up their hands at how busy they are in useless meetings and scraps them
    - Eventual dumpster fire as something that should have been communicated, wasn't


## Approaches
- Pretty much the entire company including its investors need to be considered when building anything, even if it’s a cursory confirmation that they don’t need to care
    - This is is NOT a license to build by committee
- You _could_ just automate every job outside the product team, but you better have an ironclad plan on how user acquisition and support is going to work, among other things
- Or more simply, automate enforcing the consideration of non-product stakeholders

Forgot non-user stakeholders

## Description
- More than one business has built something they have no business building
  
## Disproof
- A very clear arrow from your product to the way you want to change your market

## Consequences
- The great thing with problems is they create viable business in isolation
- The problem with problems is that you typically need to resource a company around the ongoing delivery of a solution to them.
    - If you end up building/operationalising for something outside your core business, you’ll end up trying to build two businesses
    - This leaves you stuck with an undersupported second product line that suffers because you can’t leverage economies of scale or customer segments
    - Or you end up competing with and cannibalising your primary (hopefully successful) business
    - You screw this up, loose good people or overspend and have to fire people
- Multiple entire multi-million product lines have been shit-canned before launch (microsoft courier, google ara)

## Causes
- If you don’t have a clearly articulated mission, people tend to forget it
- Someone, usually underacquainted with the problem domain, tries to ‘diversify’ or ‘expand margins’
- But also happens if the product team is so lost in the weeds that it forgets to look up

## Approaches
- Build a culture that knows why we’re here, that repeats it often enough to remember and rarely enough so it doesn’t become trite

Forgot the mission

## Description
- Any time spent planning and refining a product with negative profitability is kinda redundant no?

## Disproof
- At least a cocktail napkin with some idea of how much net money you could actually make from this

## Consequences
- The funniest thing would just be to run out of money building something
- The saddest thing would be to build something that makes negative money due to operating costs

## Causes
- Usually happens if the product is disconnected from the P&L
- When staff / operating costs are jealously guarded due to wage negotiating drama, making opex forecasts impossible
- Skill issue in the person doing the modelling, who failed to grasp (and vet) the cost of actually operating these things

## Approaches
- It may not be the work of the product team to do the modelling, but they damn well better be pushing for it to happen
- Variable costs better be verified by the teams actually generating said costs
- If you’ve got a centralised finance team doing the modelling, I guarantee you their actual understanding of the dynamics of how these numbers scale won’t be as accurate as the teams generating revenue and costs
- The business viability not only involves the cost to build, but the cost to sell and often the cost to operate
- If there’s not a positive number at the end of this, or a number at all, you had better understand where the money is coming from and for how long

Forgot viability

## Description
- You’ve cooked up the perfect business plan, only for engineering to laugh you out the room 

## Disproof
- You’ve had maybe one conversation with someone who knows how much it costs to build things

## Consequences
- It is very easy to spend weeks ‘refining’ something that’s impossible to build; these papercuts add up and you end up quarters behind
- You could operationalise and spend money on headcount/gear for a business that just won’t exist within your timeframes because you can't build the enabling product
- Do the hilarious thing of promising a product to customers after a cracked-out whiteboard envisioneering session
- At the very least you’ve wasted time and money, and likely pissed some people off

## Causes
- This is still surprisingly common in ‘product led’ companies that are actually product management led, where the PM lacks technical skill or common sense to verify early
- Also occurs when decisions to solve a problem don’t come from the product team itself but again there, you have bigger problems
- Can also be where engineers once got blamed for getting a high level estimate wrong, staunchly refused to make more/without exact details of what’s being built, and that’s just how it’s done now
- Obviously, if engineers are silo’d or only assigned in a waterfall fashion this makes the problem 10x worse

## Approaches
- Maybe talk to the engineers?
- But seriously, come to terms that all estimates have error margins and be clear that the less information an estimate is made with the bigger said margin. Then do your estimates and proceed with an operational budget for that risk
- Be very sure that the ‘costs of not moving fast enough’ reeeeeally outway the costs that you’ll definitely pay of doing the opposite

Left costs to last

## Description
- You did all the hard work of contextualising problems in light of the user and their constraints, and then all thought of the user got eroded away as you went over the problem again and again

## Disproof
- A final draft that still has a notion of the user

## Consequences
- See most of section 1

## Causes
- Problem refinement is a noisy, multilateral process that takes place linearly in time. Old information gets buried by new information by virtue of the brain literally not being good at keeping everything in mind at the same time
- Focus loss is multiplied when: multiple people are performing refinement, if discussions are non-threaded and not organised, if planning documentation is nonexistent or constantly revised over

## Approaches
- Your choice of information technology necessarily shapes how you see the world: conversations and narratives bias towards most recent information, canvases let you see everything in one glance and give it equal weight
- Whilst this is a blindingly obvious thing to avoid, sometimes it gets lost in the wash

Lost user focus

## Description
- The loudest is very rarely the most valuable

## Disproof
- A prioritisation order based on quantified value

## Consequences
- You build for a much smaller segement than expected, lose money, die
- When enterprise customers throw their weight around and start solutionising, often in a way that doesn’t even work for them. You shackle the rest of your users with a UX legacy that they get used to and can’t break out of, trapping you in perpetual mediocrity.
- Internal stakeholders can also massively skew the selection of problems and design of solutions
    - Take operational Department A, whose admin workload might go up by 2 hours a week if a new product is built
    - A’s boss kicks and screams until the product team agrees to only launch once an incredibly complicated and niche automation is built, rife with failure modes and security holes
    - So instead of shipping something, immediately generating value and building that automation once the main solution is in prod, you’re sat there shaving yaks and losing more money in dev hours and unearned revenue than it would have ever saved Department A


## Causes
- Usually bigger enterprise customers who threaten to pull their custom
- Or a disproportionately noisy minority of non-representative customers
- Internal teams driven by their own KPIs that don’t perfectly align (this is a big topic)
  - Although this requires real fixing, in the short run just calling out the conflicting priorities and getting everyone to align on a compromise will have to do
- If product simply does not have a strong relationship with some departments or a loud department elbows in, you can end up prioritising problems that are just not as valuable to the company

## Approaches
- If it’s a big customer, learn expectation management
- If it’s the biggest customer, maybe let the wookie win until you can diversify revenues
- If it’s an internal team, ask them how this aligns with a net increase in profitability
- Figure out where you can afford to be manual-first

Prioritised the shoutiest

## Description
- You’ve found this amazing problem to solve for users who’d get huge value out of it, if only their bosses would let them use it

## Disproof
- You’ve identified the key purchasing decision maker, and have a way to make them decide to purchase

## Consequences
- You build the thing and then scratch your head about why it’s not converting
- Best case you scramble a sales strategy that targets the right people. Pain ensues as you have to rapidly learn a completely different psychology
- Worse case you’ve missed the fact that your industry works on extremely gate-kept tender processes or only buys from buddies at the country club
- In complex B2B situations, it might not only be selling to the right people but the fact there’s an entire class of (super) user with a whole feature set they’ll need (admin tools, dashboards, reporting) that your product will be completely unsellable without, which you then have to add time to build
- You run out of money and die

## Causes
- Occurs often when product gets structurally isolated from customers and value, sometimes out of a desire to ‘focus’ them on building, sometimes out of desire to ‘focus’ business development on the commercials
- Can also happen when technically smart founding teams are breaking into a domain or vertical they don’t know about
- Can also happen when the same industry is vastly different in another geography

## Approaches
- If your users are held hostage by the person controlling the purse strings, you have to consider their problems and motivations
- And as such identify two sets of problems, design for the user's, position for the chooser's
- This is almost universally a B2B problem, but it also crops up in strange places like educational products or anything bought by parents for children

identify-problems

pick-problem

create-solution

deliver-solution

evaluate-delivery

evaluate-solution