There are two worlds you can exist in.
In one world, you have a lot to do! Managing family, friends, your money, your work, your day-to-day tasks, learning new things, etc. When someone asks how you are, you are B-U-S-Y.
In the other world, you get to do it. You have wonderful friends and family, smart colleagues working on hard problems, big ideas for what your future should look like. You drop the fear and stay curious.
I try to remember this when things get stressful.
There’s a question that comes up in just about every product interview that goes something like, “Tell me about a time you disagreed with an engineer, and how you resolved it.”
I have a simple answer to this question - in the teams that I work in, we ‘engineer’ conflict every day between design, engineering and product. Being comfortable in disagreement is what prevents micro conflicts from blowing up into macro conflicts, which is what that interview question is trying to get at.
Most people are not comfortable with conflict (they want to be in the tribe, and all of that). It’s much easier to agree, or say you agree, and move on without the awkwardness of not agreeing.
But constant consensus leads to poor decision making, usually because one person ends up making all of the key decisions. Short of being a solopreneur, I can’t think of a circumstance where one person has enough context, perspective or experience to make every decision (and even then…).
There are a few approaches that I’ve found are helpful to set an expectation that you’re open to disagreement:
When I start working with someone new, I let them know I want them to have an opinion on our product, and to express it
I frame almost everything I say as ‘I think…’ rather than something more concrete
After expressing an opinion, I will explicitly ask for disagreement / opinions on where I’m wrong
Write a document and share it for comment; this somehow feels less personal than oral disagreement
Being able to operate in conflict is a sign of a team that has trust in and respect for each other, and in my experience, teams with those qualities are usually the ones performing at the highest level.
SQL is, funny enough, one of the primary reasons that I ended up in product management. I taught myself to write SQL while I was doing my MBA, and then actually learned it as an intern at WorldRemit when I had a real world (and partially Spanish) database that I could ask questions of. It helped me to solve some real business problems, and I found myself with my first full-time job in product as a result.
SQL has also taught me a few things about how to think and how to work. I often found that a query that was intractable at 3pm would seem simple at 9am the next morning. Learning about ERD diagrams deeply influenced (I’m only realizing as I write this) the way that I understand technology and approach building products (very architecturally). It also, frankly, was a point of pride to have a skill that many of my product compatriots did not.
So thank you SQL.
In the last few years I haven’t had much opportunity to write SQL, but I’ve had reason to come back to it in the last few weeks. And while the basics are still there, anything beyond relatively basic queries has been difficult to carve out time to work through.
Enter ChatGPT.
I’m still at a point where it doesn’t occur to me straight away to use ChatGPT (or Gemini, or etc) for a problem like this, though at some point it does occur to me, which is new in the last couple months. I have found these tools close to unusable for anything related to writing: marketing copy, sales emails, my own personal writing - very bad. But for writing SQL - oh boy.
Writing SQL obviously requires an understanding of the database, so I chose to create a personal GPT for my SQLing purposes. I fed the GPT creator a few table names and columns, and nothing more than that. By adding a bit of additional context to my prompts (remove records where superwave_internal = ‘true’), my GPT cranks out queries in minutes that would have previously taken me hours. Wild.
It’s not perfect. I haven’t put all of the tables and column names into knowledge yet, and when I ask for a query that requires a table that my GPT doesn’t know, it makes assumptions instead of saying ‘I don’t know'. It also selectively stored the tables and column names that I gave it. But in general, it’s a lot faster than me + Stack Overflow.
The meta-question, of course, is ‘is this good'? I find I have very mixed feelings. I can get to answers much more quickly than I would otherwise, and spend my time (in theory) on higher value work. I can also intellectually appreciate that our entire economic system rests on improving productivity. But I find there is something slightly unnerving about a skill that I (clearly) have quite a personal connection to being completely commoditized.
“Positioning starts with a product. A piece of merchandise, a service, a company, an institution, or even a person. Perhaps yourself.
But positioning is not what you do to a product. Positioning is what you do to the mind of the prospect. That is, you position your product in the mind of the prospect.”
Al Ries + Jack Trout - Positioning: The Battle for Your Mind
The road to product-market fit is, with few exceptions, long and exquisitely uncomfortable. There is nothing quite like sitting in the ‘not knowing’ of building something new that may go somewhere, or may go nowhere.
One way I’ve found to make that journey slightly less uncomfortable is to not build something until you’ve started to develop a positioning for your nascent product. Why? Because you can begin to get signal from your positioning much earlier than you can from your product, and because having a position in a market makes everything else easier:
Validating (or invalidating) your thesis
Deciding what to build, when the time comes
Developing your branding and writing marketing copy
Figuring out your business model / pricing
Selling to prospective customers
Creating a sense of tangible progress
And yet! I often see teams jump into the process of building with little thought for their position in a market, or, more importantly, in their prospective customer’s mind. I have seen it happen, and been party to it happening, for a bunch of reasons:
It’s unclear who the customer is: The team hasn’t identified a target customer, which makes it awfully difficult to position the product in the customer’s mind
Inexperience in, or fear of, talking to customers: The team doesn’t have the skills to speak to customers and extract useful information, or finds it more comfortable to just build than to talk to customers
Failure to identify competitors and their positioning: The team takes the ‘worry about customers, not competitors’ advice too far
The ‘if you build it they will come’ fallacy: The team falls into the build trap and spends most of their time figuring out an MVP they can build, and then building it, only to find out no one wants it
The need to show progress: The team is under pressure (from investors, the boss, themselves) to show progress, and it’s easier to show progress through building than through positioning and strategy development
‘Positioning is done by marketing’: Positioning is seen as marketing’s responsibility, and marketing is only involved once the thing is built
Organisational imperatives are at play: Organizations fund new initiatives on their financial calendar, which tends to lead to teams either being fully staffed or not staffed at all (and creates an incentive to get your team fully staffed, now)
Whatever the reason, the outcome of failing to develop a position is usually that your product is met with customer indifference. It’s not sufficient for a customer to be able to easily identify the problem you’re solving for them and to agree that it’s a problem - they must also understand how you’re solving the problem differently from the other options that they have in mind.
So what does this look like in practice? Most often, in my experience, developing a position in a market involves identifying the central problem of a market and leveraging that insight into product, pricing, branding, etc. One reason that positioning is so powerful is that it usually shows up in product and technical architectures, so that if you’re correct about the central problem and your competitor is not, they need to make changes very far down the stack to challenge you.
Let’s take Sketch and Figma as an example. Sketch was in market first, and believed that the central problem of designers was that Adobe was difficult to use, and they needed better tools. Figma identified a different problem, which was that design is a collaborative process, and was not just the work of designers.
Those two different insights led to two different approaches across many vectors (pricing, messaging, etc), none more important than their product and technical architectures - Sketch leaned into being a powerful Mac-only app, while Figma leaned into collaboration by being available on any platform through the browser. Figma identified a much larger problem, which is why Sketch now has a page called ‘Sketch Myths’ that looks like this:
At some point in the future I’ll write something about the process of developing and testing positioning, but for now suffice to say that if you’re not thinking about positioning from day zero of a new product, you’re making that journey to product-market fit even more difficult than it already is.
It’s been more than three years since I’ve written anything here (wild), and I’ve been thinking about how and why that’s happened. In part, it’s that life and work have been hectic, but that’s mostly an excuse. The real answers are that:
I just haven’t made time for it, and
We’re in a moment of ‘content creation’ that doesn’t really resonate with me.
‘Content creation’, at least as I perceive it, is about building an audience. It happens on a schedule - you always need to have something to say.
I find that there isn’t always something worth saying, at least not something that’s going to be relevant beyond the present moment. So I’m going to try to do something a bit different with this website. I’m going to turn it into a record of the things that I’ve learned and believe are true, and I’m going to make this blog a personal changelog - a record of new learnings and updated beliefs.
I’m doing this because I find it more interesting to uncover things that are true in the long-term than to have a new opinion on a weekly basis. I think we could use more of that in the world right now - a little less noise and a little bit more humility.
While this will be mostly for my own purposes, I also believe that there’s value in exposing your models of the world to other people so that they can understand you in a way that’s hard to get at otherwise.
Lastly, some credit is due - I’ve taken a lot of inspiration from Startupy, Rosie Sherry, Shane Parrish, and Will Larson. Brian Lovin has discussed the concept of a personal changelog before, though he means something a bit different than I do.
So with that, an unattributed quote that I read today for the first time today (here) and that has become a new favourite:
“It’s what you learn after you know it all that counts.”
This throwaway paragraph from this week’s Economist struck me as something substantial that I haven’t seen discussed much:
“Last year Amazon had a 40% share of American e-commerce and 6% of all retail sales. There is little evidence that it kills jobs. Studies of the “Amazon effect” suggest that new warehouse and delivery jobs offset the decline in shop assistants, and the firm’s minimum hourly wage of $15 in America is above the median for the retail trade.”
Do you see it?
Let’s be very clear here - working in a shop and working in a warehouse are not the same job. They are roughly the opposite job. If you work in a shop, you interface with people all day long. If you work in a warehouse, you interface with a computer all day long (and these days it tells you what to do). I have done both of these jobs (a few shops and short fork in a liquor distributor) and I can assure you the same people (except me, apparently) do not work in both of these places.
My major problem with a lot of economic analysis and a lot of data science is that it looks at everything in the aggregate without zooming in on individual experiences. I'm not sure that we should be surprised when someone who is told that their job in the local shop is gone but they’re welcome to go work in a warehouse is pissed. I would be.
Uber has had a tough pandemic. Ridership has cratered and it has laid off 25% of its workforce in the last few months. Yet, despite the pain, it feels like Uber is very well positioned when we finally return to something resembling “normal”. And the reason is that public transit is in big trouble.
Uber’s flywheel has been discussed at great length (I referenced it here). Jim Collins has written a book about flywheels, why they matter, and how to get one spinning. The flywheel is now a part of the business lexicon, inevitably destined to become as useless a term as ‘disruption’ or ‘platform’.
The less discussed evil twin of the flywheel is the death spiral. Much like a flywheel, a death spiral occurs when the combination of components in a system act as an accelerant on the system itself. The difference of course is that the flywheel accelerates growth, while the death spiral accelerates, well, death.
I’m fairly concerned that public transit across the globe is heading into a death spiral. This is what it would look like:
Let’s walk through this:
If we take the pre-pandemic volume of public transit riders as a baseline of 100, there is no chance that we return to this level for years, if ever; that results in…
Lower revenues for public transit systems, with a cost base that is little changed (whether there’s 1 person or 1000 people on the train, it still costs roughly the same amount to operate), leading to…
Lower ongoing investment in public transit systems, which are often expected to run largely as standalone entities, which causes…
A degradation of service quality, which ultimately discourages people from riding public transit, and brings us back to…
Fewer riders
And that doesn’t even consider some of the macro things that are happening outside of the death spiral, like moves towards pedestrianisation of roads in major urban centres or soaring government debts that will make investment in public transport less likely. It doesn’t look pretty.
Uber, on the other hand, looks pretty good. Its model is geared towards personal space (whether car, bike or scooter). It is geographically diversified in the extreme, and will have a birds eye view of (and exposure to) how this plays out all over the world, whether in its own operations or in those of its investments in China, SE Asia, Russia, the Middle East. And it is already making its first forays into partnering with government.
Governments could step in a stop the flywheel by making big investments in transit infrastructure, but with ridership down and debt way up that seems unlikely to happen (remember Penn Station?). It will be much easier for the government to throw this problem over the fence to the private sector. Just look at how quickly the UK government has gone from scooter haters to scooter lovers.
Whether or not this is a good outcome remains to be seen. But it looks pretty likely that we’ll end up with much more privatised transit systems.
I have started to encounter the same two problems again and again when building products, and both are related to the MVP mindset:
A product/feature is built as the smallest possible thing that might add value to a user, with no plan, resource or expectation to follow-on that work going forward, regardless of whether the feature is working or not; there is always something else to do.
Because the smallest possible thing is being built, there is very little consideration of how it will interact with the rest of the org, what the cost of ongoing support will be, or for what use cases it will fall down and force us to work on it even if we don’t want to.
The MVP mindset is leading to a proliferation of zombie features that won’t be improved yet won’t be killed, which to at least some degree shows a level of disrespect for the people that have to use them. It means that product teams can’t focus because they support more products than they have member of the team. The evolution of SaaS has addressed this at least somewhat - we can pay someone else to work on the things we don’t want to - but for core, user-facing products and features we have a long way to go.
Btw, this makes me think of this from Reforge:
We spend so much time looking at all the channels and all the tactics and all the hooks without understanding that it’s usually just one big thing that tips it, so maybe we should go deeper instead of just going MVP.
With Moore’s law seeming to reach its natural/physical limit, gains in computing power are now coming mostly from stringing chips together, and from chip specialisation (Marc Andreessen discusses this here). Similarly, as the knowledge that any one person or small group of people can accumulate hits a natural limit, the number of scientific papers authored by more than 1000 people is exploding.
For me, the story of the 2020s will not be one of pure accumulation of processing power or knowledge. It will be how we’re able (or not able) to manage and optimise the connections between billions and trillions of nodes, whether human, computer or otherwise. Stay tuned.
A conversation I had a few weeks ago with a friend who founded a successful SaaS business really stuck with me. I was pushing him on their ability to sell into CTOs and CIOs who have no interest in being locked into a SaaS product that can extract increasing rents over time. His response was something like “would you rather be locked into our product, or into the code that a developer wrote who might not be with you in six months?”. It’s a strong angle - the cost of supporting orphaned, often undocumented code is high, though it’s often hard to see in the present.
A question that naturally follows from this line of thinking is: how do you measure the cost of orphaned code? The easiest way to sell a SaaS product is to evidence a high ROI and then deliver on it. But how do things that are hard to measure, get measured? My sense is that the next wave of successful SaaS companies will be able to measure their impact to a level of precision we haven’t seen before. As a sales tool, they’ll be able to look at an organisation, maybe ingest some of their data, and identify where the problems and opportunities are. Advertising moved almost entirely to Google and Facebook because advertisers could get an exact ROI on their investments. What if Slack or Zoom or Google told us not just how many conversations are happening, but where they’re happening and where they’re not happening, and gave us the social graph of the business?
Going forward I’m planning to pay more attention to things that are hard to measure. There will be a lot of opportunities in that space.
Safi Bacall talked a while back about his writing process, which is to write fast (put something on the page), bad (don’t worry about grammar) and wrong (don’t worry about facts). This works because it frees up the mind to get into flow, and because you can always fix it later.
I’m exploring what else this principle can be applied. To-do lists are a place to start - that task that you’ve been staring at for days and don’t know quite how to get going. Taking a ‘draft’ mindset into non-writing activities turns out to be a pretty good way to get unblocked. There are some things you need to do the right way the first time around. But not many.
I wrote a while back that I thought we’d start to see companies enshrining independence in their charters and business models. I now have my first, best example: Ghost!
The opportunity to build scale businesses with really small teams has never been bigger. I expect we’ll see more teams commit to independence when they figure out that they don’t need VC funding, or when they’re in a market that just can’t support VC-type returns.
There’s something else that Ghost has going for it that’s even more important: it has also enshrined customer alignment in its charter and business model. Ghost has taken a well-trodden open source model (sell the services and lock in your customer) and blown it open by giving their customers full ownership of the whole technology stack.
The businesses that get me the most excited these days are the ones that are super-aligned with their customers. They don’t just talk about it, they put it in their business models. They either build a great product, and continue to build a great product, or they die a quick death. Lambda and Earnin are great examples. Ghost is taking it to the next level.
UPDATE - Another one: https://www.beckershospitalreview.com/ehrs/don-t-go-public-and-don-t-do-deals-here-are-epic-s-13-guiding-principles.html
I find it’s often the case that the best product or business books aren’t explicitly about product or business at all. On the other hand, some of the worst books on these subjects are the ones that try to address them the most directly.
I finished reading René Redzepi’s A Work In Progress earlier this week, which is in no way a business book (to the contrary, at the end of the book his restaurant is deeply in the red). A Work In Progress is a book about a team’s creative process, the combination of sheer effort + serendipity that creativity requires, and an attempt to make that creative process sustainable. It’s the best product book I’ve read in a long time.
Something I have noticed about successful people (define successful as you like) is that they tend to stay very close to their own personal reality. By “own personal reality” I mean things like: how (objectively) good they are at their job, the quality of their relationships, or the state of their finances. When a gap opens up between our perception and reality in these areas we often run into trouble. Some great ways I have seen to stay close to your reality are:
Put your ideas into the world to find out if they resonate
Demand (real) feedback from others, and be prepared to hear it
Have a monthly update with your significant other to find out whether you’re on the same page about how things are going
Get an objective view of your personal finances (eg. use a tool to aggregate and track your spending, pay your credit card down from your savings as purchases happen, not at the end of the month from future earnings)
Write down your technique for anything so that you can see what it is, and it can be critiqued and evolved (you have a technique for everything, whether you recognise it or not)
Reality is not always kind to us, but that doesn’t change the fact that it’s reality and that we should try to stay as close to it as possible.
There are two ways to find balance. This way:
Or this way:
Neither is right or wrong, they both balance. But they feel pretty different.
One of the hardest things about a rapidly scaling business is getting the org structure right and making sure that all of the different parts of the org are speaking to each other. Usually communication is breaking somewhere, and most often it is breaking everywhere. Communications architectures haven’t been agreed and as a result every team uses different tools and different cadences to communicate.
One theoretical way to address this would be to treat each part of the org (and possibly each team) as their own API. I don’t mean just technical teams (Bezos has already addressed this). I mean every org function: engineering, product, people, finance, CS, etc. Every function sets their own rules for how they should be communicated with, how often they should be communicated with, how quickly they should be expected to respond, etc etc etc. These rules are documented so that everyone, including new joiners, knows what they are, and so that the rules can be reviewed and updated as necessary.
There are, of course, tools that are trying to solve these problems. Slack is trying to be the single point of integration for the whole org. So is Okta. Netsuite provides a configurable set of rules for how people should interact with accounts processing. Individual teams and orgs implement “how to work with me” docs that are shared and effectively act as human-level API documentation (@chughesjohnson spoke about this at length in High Growth Handbook). But it all feels very disjointed.
I see a few problems with the current approaches:
Too generalised to address company- or industry-specific differences (Netsuite has about 500 fields, of which I use 8)
Too unstructured (I can set my own rules on Slack, but they aren’t communicated to anyone else and they can drop something on me at any time and in any format. My rules are also different from the person in my team sitting next to me)
No organisation level framework/direction for thinking about the problem
No organisation level buy-in to a specific solution/approach
I would love to see an implementation of this, I’m not sure if it’s a no-brainer or an absolute disaster. It is definitely true that left to their own devices, most people won’t set any rules at all. But the amount of thrashing that happens in every company because communication has no structure has to be either a great potential business or a huge potential organisational opportunity.
Yesterday California passed a bill that will turn gig workers in the state into employees of the companies they work for. The big problem with this from the perspective of Uber, Lyft, DoorDash et al is not the explicit cost of it, but the fact that it turns what was a mostly marginal cost (drivers get paid when they pick up a paying passenger) to a largely fixed cost (drivers will get paid whenever they’re on the road, regardless of whether they have a paying passenger or not, and will probably get some benefits which will be paid even when they aren't on the road).
The big problem is that this breaks Uber’s flywheel. In 2014 David Sacks posted this on Twitter:
It’s a good representation of what Uber does: more drivers -> greater coverage -> faster pickup + lower prices -> more demand. This is built on a classic supply and demand economic model, where more supply leads to lower prices and new demand.
The California law throws a wrench into this flywheel. A higher fixed cost per driver means that Uber needs to either constrain the number of drivers on the road, or to stimulate demand to leverage the fixed cost of paying a driver a wage and benefits. Fewer drivers throws the whole flywheel into reverse, a classic death spiral. And we know that this is a largely commoditised service where demand generation has been coming mostly from price incentives, which are not sustainable.
While this is bad for Uber it is actually much worse for Lyft, who are almost exclusively in the US and are now vulnerable to this decision being replicated in state after state. Ignoring the politics of the decision, it might turn out to be a great reminder that flywheels don’t operate in only one direction.
I wonder how long it will be before there’s a generation of companies that commit to staying independent and enshrine it in their company charter, in the same way that B Corps have committed to considering all stakeholders in the running of their businesses. By staying independent, I mean committing to either IPO or ICO or stay private. A commitment to not sell out to Big Co.
Counterintuitively, I think the explosion of VC funding has not been good at all for competition. Yes, lots of new (software) companies get started. But as soon as they take that first dollar of VC funding, the company commits to optimising for an exit in the next 4-7 years. They also give up at least some control over what that exit will look like.
This means the company will definitely not stay private, which leaves either an IPO or exiting to Big Co. From a VC perspective, exiting to Big Co means an immediate realisation of a return, in full. IPO’ing, on the other hand, means at least a partial lockup and facing the harsh realities of the public markets. For a VC, Big Co looks pretty good.
For the entrepreneur (and her employees), it doesn’t look quite so good. She gets some realisation of her shares, but the rest of them are vesting. She’s probably not a good fit in Big Co (being an entrepreneur) and soon realises her baby is sold and gone. Not great.
My guess is that some smart companies will start to find ways to monetise the value of committing to independence. They will use new funding mechanisms (crowdfunding, ICOs) to build their businesses without committing to a quick financial exit, and will build a super-credible brand around their independence. I don’t know of any companies that have actually enshrined independence in their charters yet, but Brewdog and some of the D2C brands are at least part-way there.
I was having a beer with a couple friends last night and was asked the question I almost always get asked when I tell people I work on an API: what the hell is an API? So I thought I’d try to explain it here, in the simplest possible terms. I’m also writing something about why APIs matter and what they can teach us about ways of working, so this will be a useful reference point.
What is an API?
An API is a set of rules that dictate how two pieces of software should communicate with each other. Those rules are written in code and documented in text so that they can be easily understood. API stands for Application Programming Interface, but you don’t really need to know that because everyone just calls it an API.
APIs standardise software interactions so that we don’t need to come up with new rules every time we link two software programs together. A good parallel would be the English language. Two people who have never met but who follow the rules of English grammar and syntax are able to communicate without needing to agree the rules of communication every time they meet someone new.
Give me an example.
My favourite example is flight booking. Imagine your go-to flight booking site (Google Flights 👊). Every airline has an API that allows booking sites to retrieve flight information from it. When I use Google Flights, I give it my origin, destination and dates. Google Flights takes that information and sends a request to all of the airline APIs (British Airways, EasyJet, Wizz, etc) that it has access to. The airline APIs send a response to Google Flights that contains the flight times, stopovers, price, etc. And Google Flights then displays that information to me.
What’s happening behind the scenes?
Without getting too far into the weeds, an API will offer a bunch of actions that Google or other travel providers can take by using the API. These actions are exposed as ‘endpoints’. An endpoint is basically a URL, which looks like this:
https://api.ba.com/selling-distribution/AirShopping/17.2/V1
Each endpoint allows me to take a specific action, which is often called a ‘resource’. If I look at the British Airways API, some of the actions I can take (resources I am offered) are flight availability, seat availability, pre-purchased luggage offers, and flight booking. AirShopping, in the URL above, is the flight availability endpoint.
APIs work on a request/response basis, like any good conversation. At a very high level, I can make a request to an API to retrieve data (as in the example above), to create new data (if you went on to book the flight), or to update or delete existing data (if you changed or cancelled your flight). The API will respond either by providing the data I have requested, by confirming that I have successfully created/updated/deleted data, or by telling me I’ve done something wrong.
If I wanted to use the AirShopping endpoint above, I would pass a bunch of data to that endpoint (origin, destination, date, etc), and I would receive a response with a bunch of data in return (available flight times, cost, stopovers, etc).
Why do APIs matter?
APIs matter because they make it easier for teams and companies to work together. When Uber launched in 2009, it didn’t have to build its own maps or spend months working with Google to integrate Maps into the Uber app. Uber’s engineers simply looked at the Google Maps API documentation and figured out how best to use Google Maps given the rules that the documentation provided them with.
APIs allow companies like Uber to launch and scale quickly as they can consume services that they don’t need to build themselves (maps, payment, SMS, etc). At the same time APIs also allow the companies who provide those services (Google, Stripe, Twilio) to offer them to what is effectively the entire world.
APIs are also a fundamental building block of the internet, and have played a major part in allowing the web to scale to the degree that it has. When you enter a URL into your browser, your browser is making an API call on your behalf. It requests the data that sits at that address (the URL) on a server somewhere, receives the data in a response from the appropriate server, and then follows the instructions in the data that describe how the page should be constructed. APIs are behind everything.
That’s it?
That’s it. There are some definite best practices in building and using APIs, and there is not a single API standard that is universally agreed on. But for the purposes of ‘what the hell is an API?’, that’s all you really need to know!
The 10x engineer debate has surfaced again, to the delight of the internet.
10x engineers are fun to talk about (and do exist, for what it's worth!). But there is a lot of nuance missing here, particularly concerning where that engineer's product is in its lifecycle.
A product that is very early in its lifecycle has the characteristics of a multiplicative system. Multiplicative systems have a special property, which is that if any part of the system is a zero, the result of the entire system is a zero (eg: 12 * 5 * 0 * 10 = 0). For an early stage product, this means that if your architecture or product-market fit or distribution (etc.) aren't right, your product is sunk.
A product that is in a more mature stage of it's lifecycle starts to take on some of the characteristics of an additive system. Additive systems can have zeros in them without summing to zero (eg: 12 + 5 + 0 + 10 = 27). Yes, you could still have a catastrophic event that takes the product to zero, so it's not a purely additive system, but the failure of single features or strategies don't immediately sink the ship.
This matters because the type of system impacts the calculation of an engineer's impact. In a mature product you have 10x engineers that are just way more productive and creative than other engineers, and help the product to make step function changes. But in a new product, you have a totally different dynamic, which is that engineers can make the difference between a product living or dying. I have worked with engineers that again and again can turn a 0 in to a 1 (or even a 0.1) and keep the product viable. That impact actually can't be calculated:
(1 - 0) / 0 = 🤯
This is a pretty simplistic model for thinking about engineering impact, but suffice to say the 10x meme is selling some engineers short.