# Faster Times

This file is a full-text archive of Faster Times posts in one place for easier reading, indexing, and use with LLM tools.

A companion archive of links and notes is available at https://fastertim.es/links.md.
# The 2026–27 budget

## The direct damage is real but manageable. The bigger issue is that Labor keeps signalling indifference to the startup ecosystem.

The Albanese government’s 2026–27 federal budget, heralded as the most consequential in a decade, is here, and Australian startup investors and founders are not happy. Specifically, [the 50% capital gains tax (CGT) discount will be replaced by cost base indexation for assets held for more than twelve months, with a 30% minimum tax on net capital gains accruing from 1 July 2027](https://www.abc.net.au/news/2026-05-12/budget-2026-share-market-investors-cgt-changes-small-business/106669784). On its face, this looks like a doubling of the exit tax burden for startup founders, employees, and investors, so the response has, understandably, been overwhelmingly negative.

I have two critiques. First, the practical reality. 

The messaging for this budget has revolved around fixing generational inequity, particularly in terms of home ownership. One of their goals seems to be to disincentivise a certain type of property investment, and this explains the removal of negative gearing. But it doesn’t explain these CGT changes. By replacing the 50% CGT discount with cost base indexation against inflation, this budget harms startup founders, employees, and investors[^workedexamples] much worse than virtually any other asset owners, especially real estate speculators. The cost base of startup shares in Australia is usually between zero and close-to-zero, because employees are granted shares for free, in exchange for their labour, especially when the startup they work for is essentially worthless on paper. There is little benefit to startup shareholders from cost-base indexation. Expensive, more slowly-compounding assets like investment properties? These will benefit greatly, and in many situations, end up better off than under the previous regime. Now, this is before we factor in scrip-for-scrip rollover, ESIC tax offsets, the 50% active asset reduction, active asset rollover, ESVCLP returns, the 15-year exemption, other unchanged concessions. But, given this dynamic, it’s easy to understand why people in startups feel like the target of this change.

Does this equate to a doubling of taxation for people building startups? And does this mean a plurality of Aussie founders will flee overseas? The answer to both of these is obviously “no.” However, the impact *will* be negative, and due to the complexity and lack of clarity, I can understand why the speculative reactions have ranged from rage to confusion (CGT is not double taxation, despite what you’ll hear on LinkedIn this week) to fear mongering to verging on hysteria.

Which brings me to my second critique: optics. If the government wants engagement and support from startup leaders, this move seems clearly foolish to me. 

Labor, at both the federal and state levels, is now deep into a multi-year string of regulations despised by startup founders: the proposed Division 296 tax on unrealised superannuation gains above A$3M, the mooted increase to sophisticated investor thresholds (from $250k income / $2.5M assets to $450k / $4.5M), the abolition of non-compete clauses below the high-income threshold, the Right to Disconnect, Victoria's work-from-home legislation, tightened ESS reporting requirements, and now the 2026–27 CGT reform. 

[The government has published](https://budget.gov.au/content/bp2/download/bp2_2026-27.pdf) a combined A$3.6B five-year revenue estimate for the negative gearing and CGT package. Most of that will likely come from property: negative gearing changes and the indexation-net-of-relief on long-hold property gains. The slice that comes specifically from founders and equity-holding employees is probably small;[^estimate] probably in the low hundreds of millions per year, against an existing CGT base of roughly A$25B annually.[^cgtbase] As a share of total Commonwealth tax receipts (~A$680B), it's a rounding error. Even granting the housing rationale, the collateral damage on the startup ecosystem is poorly compensated by what the package actually achieves.

To the federal budget, this is an insignificant amount of money, but to individual founders, this is potentially significant. “Potentially,” because, given the existing exemptions and the vague statement that the government will consult on the impact on the tech and start up sector, we don’t really know what the impact of this will be. 

But the optics may matter more than the eventual outcome. Labor is now the dominant force in Australian politics, the party startup employees have historically backed, and the party that says it wants Australia to be more than a quarry for the world. Yet it has now made clear that it doesn't love us back. That perception alone, before a single dollar of additional tax is paid, will chill startup formation, local hiring, and the kind of ambition that builds globally competitive companies. Is that a worthy trade off?

Rate-tweaking alone won't fix the underlying signalling problem. More importantly, the government should prove their support for the ecosystem outside of the budget, through surgical reforms that will meaningfully improve the outcomes from and experience of building high-risk, high-reward companies here in Australia. Australian startups need fewer friction points. [The shortlist is fairly clear:](https://inflectionpoints.work/articles/industrial-policy-for-tech-workers) an R&DTI that's simple to claim and aligned to iterative software work; an employee share scheme regime that genuinely turns staff into partners rather than tax problems waiting to happen; an angel market with enough certainty to seed the next generation; labour mobility that lets talent move quickly to the teams shipping value; and a skilled-migration pipeline that brings great engineers to Australia while growing more of our own. Done well, this won't just lead to more innovation and improved productivity, it should fix the vibes issue along the way.

The teased consultation is an opportunity. If it produces nothing, or produces a narrow technical fix that misses the broader signalling problem, the natural advantages of markets like the US will continue to do their work, and we'll get [the kind of brain drain I warned against last year](https://inflectionpoints.work/articles/industrial-policy-for-tech-workers).

[^cgtbase]: Estimated from Treasury's [Tax Expenditures and Insights Statement (December 2024)](https://treasury.gov.au/publication/p2024-607085), which reports revenue forgone from the CGT discount for individuals and trusts at A$22.7B in 2024–25. Because the discount roughly halves the assessable gain, the tax actually collected from discounted individual and trust gains is of similar magnitude. Adding company and complying super fund CGT brings total annual Commonwealth CGT collections to an estimated A$25–30B.

[^workedexamples]: See [Henry Innis in Mumbrella](https://mumbrella.com.au/capital-gains-whack-spot-on-for-real-estate-crippling-for-start-ups-922618) (A$15M agency sale split three ways, plus a senior data scientist ESOP scenario), [Gilbert + Tobin](https://www.gtlaw.com.au/insights/the-new-rules-of-the-game-what-the-202627-federal-budget-means-for-private-capital-in-australia) (mid-market PE worked example on a A$150M gain), [PwC](https://www.pwc.com.au/insights/federal-budget-tax-analysis-and-insights/investment.html) (founders "may expect a meaningful uplift in their effective CGT rate"), [Baker McKenzie](https://www.bakermckenzie.com/en/insight/publications/2026/05/australian-federal-budget-2026-2027) (on the ESS deferred-taxing-point implications for employees), [Corrs](https://www.corrs.com.au/insights/australian-federal-budget-2026-27-corporate-tax-measures) ("indexation would provide minimal benefit (as the indexation multiple would be applied against a small base)"), and [William Buck](https://williambuck.com/tools/federal-budget-2026/capital-gains-tax/) ("as there is no cost base to index, almost all of the gain will be subject to CGT").

[^estimate]: Treasury has not published a sectoral breakdown of the A$3.6B revenue estimate. The "low hundreds of millions per year" figure is my own back-of-napkin estimate, derived from Australian VC exit volume and an average effective tax increase of around 23 percentage points on the assessable gain. Treat this as a rough order-of-magnitude figure, not a precise number.

Tags: advice, startups, society

# You need more engineers

Most startups, and companies in general, need more engineers, particularly in teams other than product development. This is especially true in the age of vibe coding, where each engineer, including junior engineers, can get exponentially more done.

Despite all the talk about _cross functionality_, _innovation_, and _efficiency_, most startups have a misguided notion that engineers belong in the product team, working almost exclusively on the products they sell to customers. Integral to the theory of value for technology companies is the idea that engineering effort, delivering operational efficiency and revenue-driving innovation, is more valuable than the labour invested. But many startups seem to miss this lesson when operating their own companies: everything inside the company gets solved with process, headcount, and meetings.

Customer support teams expand because nobody automated workflows properly. Revops teams emerge because systems do not integrate cleanly. Finance teams spend huge amounts of time reconciling data across fragmented tools. Sales teams manually research leads. Across all of these functions, LLMs can automate a lot of human labour. But the reality is that there are no great turnkey solutions for these problems. Partly because the applied-AI product space is immature, and partly because there is a lot of diversity between companies, making one-size-fits-all solutions difficult or impossible to build. This is why Palantir, Google, OpenAI, Anthropic, and most other ascendant AI companies employ forward-deployed engineers to rollout and customise their products for new customers. These companies probably won't give a forward-deployed engineer to your fledgling startup, so you need to hire some of your own.

A skilled engineer can absolutely automate the vast majority of your support tickets, finance and legal tasks, and sales prospecting. Inference, while expensive, is already cheaper than human labour, so this should be excellent for your gross margins, CAC, and G&A spend.

If your team is big enough to have well-defined departments, but you don't have a few engineers scattered throughout these teams, you're probably under investing in AI deployment. If you're building an AI-enabled product, this should be especially embarrassing. You should hire some more engineers.

Tags: advice, startups, operations, technology

# Industrial policy for Australian startups

Recent policy moves suggest the Australian government may squander a golden opportunity.

Starting with the proposal to [tax unrealised capital gains inside superannuation above a $3 million balance (Division 296)](https://www.superannuation.asn.au/media-release/asfa-fact-sheet-on-div-296-and-proposed-changes/), which is a direct threat to angel activity. [Self‑managed super funds are a vital source](https://wilsonassetmanagement.com.au/wp-content/uploads/2025/04/WAM-Discussion-Paper-Division-296.pdf) of patient capital for small growth companies and that taxing unrealised gains would force trustees to de‑risk by shifting capital from unlisted, higher‑growth companies into liquid assets like property or listed shares; paying tax on paper gains could require investors to sell holdings early, creating a success penalty and structurally shallowing the pool of angel capital. 

Moving onto the equally damaging "sophisticated investor" wealth test. At present, [Australians must earn $250,000 per year for two years or hold $2.5 million in net assets](https://www.aph.gov.au/Parliamentary_Business/Committees/Joint/Corporations_and_Financial_Services/Wholesaleinvestor/Report/Chapter_2_-_The_wholesale_investor_and_client_tests) to invest in many early‑stage opportunities. This is already an extremely high bar, and [the current government is considering](https://www.afr.com/policy/economy/labor-to-overhaul-sophisticated-investor-test-20231219-p5eseg) raising it to $450,000 and $4.5 million, locking out even more potential angels. 

Talent dynamism is also under threat. Victoria is moving to legislate a [right to work from home two days a week](https://www.theguardian.com/australia-news/2025/aug/02/victoria-work-from-home-two-days-a-week-law-jacinta-allan-labor-party-state-conference), while federally the [Right to Disconnect](https://www.fairwork.gov.au/employment-conditions/hours-of-work-breaks-and-rosters/right-to-disconnect) gives employees the legal right to ignore work communications outside ordinary hours. These reforms may make sense for large employers, but founders have told me that they are already concentrating more hiring in the US, where the cost of a hiring mistake is far lower, under the expectation of further employee protection regulations.

Is Australia destined to become a training ground for world-class founders and engineers, only to see them move to the US as their careers take off? This is not our destiny, but we need smarter, industry-friendly policy to build an alternative path, where startups start, thrive, and therefore stay in Australia. Let’s be the beneficiary of brain drain, not the victim.

This is why I jumped at the opportunity to contribute to [Inflection Points](https://inflectionpoints.work/articles/industrial-policy-for-tech-workers). Inflection Points exists as a publication to disrupt Australian policy parochialism, recommending pro-growth reforms, aiming to improve Australian policymaking. 

In my piece, *[Industrial Policy for Tech Workers](https://inflectionpoints.work/articles/industrial-policy-for-tech-workers)*, I outline the problems and potential solutions to the regulatory problems faced by the Australian startup ecosystem. I cover a lot more than my complaints above.

Please do give it a read, and let me know what you think.

My thanks to [the team at Inflection Points](https://inflectionpoints.work/authors) for their help putting this together, and inviting me to share my perspective.

Tags: advice, startups, society

# We’re selling outcomes now

Almost all software businesses sell tools. Something that a person or team can use to get their work done and achieve an outcome. However, this is changing. Thanks to the proliferation of extremely capable Large Language Models, for the first time ever, it's possible for software businesses to sell outcomes, taking human labour mostly or entirely out of the loop. This will be a big shift that completely changes what we all build, how we build it, and how we sell it. This evolution will disrupt every SaaS company that does not eventually adapt.

Long ago, the software industry adopted the service (*i.e.,* subscription) business model. We used to sell tools, then we started renting them out. The software itself didn't change much, though. Now, the software is finally catching up to the service model. Like other service businesses, software businesses can now sell *outcomes*.

Every problem has potential solutions in the form of *tools*, a *tools-as-a-service*, and *outcomes-as-a-service*.

Let's use laundry to understand these distinctions better:

- A washing machine is a tool: it helps you to get your work done more efficiently, but as an owner of one, you still need to do the work yourself.
- A laundromat is a tool-as-a-service. You pay to use tools owned and managed by someone else. Yet again, you need to do the work yourself.
- Dry cleaners are an outcome-as-a-service. You pay for someone else to do the work. You're not paying for a tool, but for the outcome of clean clothes.

In digital, businesses typically either rent software tools for their in-house team, or they pay an agency to do the work for them. For example, you can pay for a design tool like Figma, or you can just pay a design agency to do the work for you.

What's new in 2025 and beyond is the ability to buy the outcome not from an agency, but directly from your software vendors. This is because Large Language Models make software an order of magnitude more capable.

Your software product today is a tool, and it might already be possible for you or a competitor to build an AI-first product that does the work for your customers without any ongoing effort on their part. If not, it'll probably be possible soon. Either way, a level of disruption that was not possible a few years ago is now possible in almost every software category[^disruptive-sustaining].

[^disruptive-sustaining]: This is not to say that, in the terms of Clayton Christensen's [The Innovator's Dilemma](http://claytonchristensen.com/books/the-innovators-dilemma/), Large Language Models are more of a disruptive (*i.e.,* better for startups) than sustaining (*i.e.,* better for incumbents) innovation. In terms of SaaS, I think AI is probably more of a sustaining innovation, that will nonetheless be disruptive to many lazy and ineffective incumbents.

Tags: advice, startups, ai, highlights, strategy

# All-in-one is the laziest early-stage product strategy

If your product strategy is to take two, three, four, five, or more products, recreate them 10-20% worse, but bundle them together into an all-in-one package, your startup is doomed to mediocrity.

That's not to say bundling does not work. It can and often does. If two features or products are extremely complementary, and benefit greatly by proximity and tight integration, bringing two ideas together can create massive customer value. Bundling can also help you to fight up-and-coming competition from feature-as-a-service companies (i.e., companies selling just one simple, easy to replicate feature) by cornering the market before they do.

Bundling for the sake of bundling, however, is almost always a bad idea. Even if you manage to hear a customer tell you they don't like logging into multiple systems to get their work done, the reality of competing with every company in four or five verticals is brutal, distracting, wasteful, and uninspiring. Almost every company that tries this ends up with either all of their revenue coming from one pillar of their product, or a spread of revenue across virtually unrelated products that is so thin that prioritisation becomes impossible. They spend all of their time catching up on building commodity features rather than innovating on new ideas that've never been done before. And, new ideas, that are good and well executed, always create the most value.

What about Rippling or Deel? These companies have become the contrarian standard bearers of the go-wide-not-deep strategy. However, I'd argue their product strategies are more conventional than they tout. Today, the best advice is to start narrow, win in your initial market, and then expand when you can truly afford the distractions. Rippling and Deel win because they've truly innovated on their core product. Hiring employees overseas is a massive pain point. They solved this problem resoundingly. They just did it way faster than most startups, so they could afford the distractions much sooner. This is likely the result of the fact that much of their product innovation is actually commercial, as opposed to being solved through engineering. 

If your CEO or product leader tells you something like "customers hate logging into multiple systems, so we're going to give them a single solution for everything", you should quit and join a startup with a truly differentiated and opinionated product thesis. A company that actually wants to build something that has never been built before. Or, at least take the high salary, low ESOP compensation option, because your company will never be generational unless it pivots.

If you are the CEO or product leader currently stuck in a failing all-in-one strategy: pivot. The good thing about having a broad product is that you should have plenty of insights into what areas have the most opportunity for disruption and innovation. Find an area to double down, and a pathway towards deprecating some of the bloat. You'll create a much more successful product that way.

Tags: advice, startups, product, strategy

# Startup leadership is about saying no to good ideas

Today, most startup leaders take strategy seriously and understand their role in saying yes, and no, to the right things to create focus and direction for their team. They often get one very important thing wrong, though: Startup leaders often think of good strategy as saying yes to the good ideas, and no to the bad ideas. If everything you build is a good idea, assuming your team can execute, you'll succeed, right?

Unfortunately, it's not that simple. Startups are idea rich and resource poor. In fact, startups are good idea rich. This means, even if you cut out all the bad ideas, you'll still end up with way more than you can execute.

Great startup leadership is about saying no to the bad ideas, sure. But mostly, great startup leadership is about saying no to most of the good ideas too. The decisions that make a mediocre startup a generational company are the decisions to not pursue legitimately huge ideas in favour of even better ones.

Clear direction and laser focus is the most important property of a high-velocity venture. Every time you say yes to something new, whether it's a feature, a sales channel/strategy, a hire, you dilute focus and distort the clarity of your direction. The more you do, the more mediocrely you execute. This is a universal truth.

Behind every great company is a graveyard of fantastic ideas, abandoned, or never even started. Talking to founders, many have a tonne of spare ideas for products, features, and startups they could pursue. This is because they've rejected these ideas already. Many regret these decisions: why can't we just do more? This is why good leadership is difficult. You need to reject independently good ideas for the sake of the bigger picture. If it was just about killing the obviously bad ideas, creating a generational startup would be pretty easy.

Tags: advice, startups, highlights, strategy

# Advice for startup employees

Working in an early-stage startup is different to working for a larger company: while many people fail to get anywhere in startups, others skip years or decades of career milestones. Granted, every startup is different. However, I have noticed a few common patterns across many startups that describe the most successful talent. 

## Understand what you're here for.

Is your job to get things done, or is your job to create an outcome? This is crucial to understand first and foremost because it determines the mindset you should bring to your role.

If your job is to get things done, then you should set your goals and ways of working based on this. Deeply understand the priorities (*e.g.,* which tasks need to be done instantly, which tasks can wait). Don't get too emotionally attached to the outcomes of your work as this will lead to unnecessary stress.

If your job is to achieve an outcome, your first priority is to prove yourself enough to gain as much power as you will need in order to control the things that you need to control to achieve this outcome. For example, if, as a product manager, the biggest obstacle to achieving your outcome is actually the ways of working of your customer success team, you need the power to heavily influence how they work. This is a difficult job, but it will be incredibly fulfilling if you succeed. 

## Understand what you can actually control.

I recommend directly asking during the interview process, or at least once you start, what you're actually allowed to do. Are you allowed to ruffle feathers? If so, where? Within your team? With specific other teams? Or anywhere in the company? Stick to affecting change within this defined sphere of influence until you get the blessing to branch out (assuming you want or need to).

## Over-communicate.

Send a weekly update to your manager and your team highlighting wins, losses, things that are top of mind. People in startups often fail because leaders are unaware of what they are doing. Leaders only notice the really great things, and the really bad things. If you don't communicate all of the other wins, they'll go unnoticed. You could even do it daily. Don't expect a response, though. Don't create unnecessary work for people by doing this.

## Take control of your own career development

But exercise a reasonable amount of patience. Early-stage companies struggle to find time for real professional development. Don't expect anyone to do this for you. Take control. If you want feedback, ask for it. Be specific when asking for it. General "what feedback do you have for me" is unhelpful. Ask how you went on a certain project, or for feedback on a specific attribute. If you need more money, ask for it. Be specific about what you actually want. Don't waste time on politics or negotiations. Start with your non-negotiables. If you want a six-month review, ask for it. But don't be disappointed if it doesn't happen until month 7 or 8. This is the norm given how poorly resourced startups are. If you don't like this, you should work at a bigger company.

## Rise above the gossip, politics, and bullshit.

Small companies fester gossip. This is inevitable because every single person on the team is competing for the same attention, influence, and resources, and everyone has an opinion on everything. Leaders notice who gets stuck in the mud, and who stays out of it. It's rarely obvious how much this is affecting the opportunities that are given to you, your prospects at the company, and your reputation in the market. 

## Believe in the product, company, and mission.

Delusions of grandeur power startups. The best startup employees find a way to believe as strongly as the founders. The reality is: you have no idea if anything you're doing is actually going to work long term. The things you're optimistic about will fail. The things you are cynical about will succeed. Your chances of success are far greater if you believe, though. Fake it until it's true. 

## Operate with absolute integrity in the market.

Never take an interview with a direct competitor and divulge sensitive information. Avoid all conflicts of interest. This is another one of those things that people are unaware of how much it is affecting their career within and without their current company. Just because it's legal or technically permissible doesn't mean it is fair game or good for your career. 

## Maximise salary and equity 1-2 years into your journey.

People underrate how much leverage they'll have after a year or two into their role. As a candidate, your experience is valuable, but rarely crucial. As a tenured employee, if you're talented, you'll seem completely irreplaceable due to your contextual experience. This is the best time to negotiate on comp. This may seem risky, as your comp may not come to fruition, but you should only work in an early-stage company if you truly back yourself and if you are happy to take big risks.

## Reduce cognitive load for your team, and especially your leaders.

Every time you ask for direction, you distract your coworker from another unrelated task. Make it as easy as possible for them to help you. 

- Put questions and requests at the top of your message/email, with additional context and notes second.
- Make it extremely clear when something is an actionable request and not just a comment.
- Provide all necessary context in your requests. Link to the Slack message you mentioned, the deal in HubSpot, the ticket in Zendesk, the ad creative in Facebook Ad Library, the page in Notion. If your manager needs to know certain things about a prospect to approve a deal discount, include those details in your request. Remind them what you discussed last time you met.
- Make the decision yourself, but offer your leader a chance to overrule you. *e.g.,* "I'll email the vendor tomorrow morning with xyz price. Let me know if you disagree and we can adjust approach".
- Write short, concise, to the point emails, documents, and messages.
- Only demand an immediate response if it's actually necessary.
- Adopt the communication medium of the business. Some companies are Notion companies. Some use slide decks. Others are all-in on digital whiteboards. However your team communicates, take that on. Going against the grain in this regard is rarely productive.
- Communicate and confirm priorities to eliminate ambiguity. Tell your leaders and team what you're prioritising for the day or week, tell them what you're consciously neglecting, and let them object if they disagree.
- Take every opportunity to advertise yourself and your work in front of the company. Speak at All Hands, no matter how bad you are at it. Ask the CEO if you can give them a quick demo of something you just built. Share videos of your product demos in `#general`/`#company-wide` on Slack. Dial into All Hands when you're sick or on holidays, at least occasionally.
- Don't complain. Pointing out problems is fine, whinging will make working with you feel like a chore, though. Practice extreme stoicism in the workplace.

Tags: advice, startups, people

# Find a way to believe that you will win

When building a startup, what is there to be confident in? You could start with the idea. Does it solve a real problem? Are the people with that problem willing to pay for a solution? There's also your capability. Can you build this solution? Do you have the technical ability, the social skills, the experience, the network, and the grit?

A sufficiently down-to-earth person will, by default, convince themselves that the answer to at least one of these questions disqualifies them from succeeding in their venture. This is partly because down-to-earth people are rarely successful in anything grand. It's partly because everything looks simultaneously harder and easier before you try it. And it's partly because ==all good ideas sound like bad ideas until they come to fruition.==

Every founder's answers to at least a few of these questions are wrong, especially at first. But founders are wrong in different directions. Some are too confident, some too insecure, others a mix, depending on the area. The only way to be right in every domain necessary to succeed is to first be wrong, and then adjust your opinions as new information arises.

## If it's inevitable that you'll live somewhere on the spectrum of delusion, you may as well make it work in your favour.

As a founder, you'll probably fail. If this happens, it'll probably be because you gave up. You lost faith in the problem, the market, the solution, your team, or yourself. All successful startups could have failed like this. They didn't because the founders persisted—not by blindly continuing down stupid paths, but by pivoting until the problem, solution, market, and team finally made sense.

Until this happens, it's better to believe it will. Even if your idea sucks, your network is useless, your code is busted, and you are out of your depth. That's the only way you'll make it past the great filter: your own perseverance.

If you're working on something hard, ==the first step is to choose a path==. The second is to ==convince yourself that it's going to work==, that you can't fail, and that every other approach is insane, stupid, and immoral. ==The third step is to pivot== disgracefully when you find a better way. That may sound foolish, but it is fools who win.

Richard Feynman said, "The first principle is that you must not fool yourself, and you are the easiest person to fool." This may be true for scientists. But great startups are built by fools: people who've convinced themselves they're on the right path, despite an incredible lack of evidence. Be the fool.

Tags: advice, startups, highlights, strategy

# One part of the funnel is always broken

Whether you're experiencing meteoric growth, or stuck in a stagnant rut, one thing is guaranteed: There is always one part of your growth funnel that is broken.

Founders often ask me: "At what point does this get easy?" The honest answer is never, because today's success creates tomorrows problems. Whenever you fix a step in your funnel, you create a problem somewhere else.

Top of funnel is the first growth problem a startup will face. How do I get people interested in my product? No matter how you fix this problem, when you do, you'll uncover problems deeper in your funnel. Now that you can get people interested in your product, can you actually close a deal?

And once you work out how to close deals, you'll realise how difficult it is to onboard a customer.

And once you solve that, you'll realise how hard it is to retain a customer.

It doesn't stop there. As soon as you feel like the whole funnel has been worked out, and growth is orderly and efficient, your standards for growth will raise. Achieving twenty-percent growth on $200K ARR is a lot simpler than twenty-percent growth on $20M ARR. So, top of funnel will become a problem again. How do we get a *lot* of people interested in the product?

This is when you realise your sales or onboarding process can't handle this volume of new customers, so you'll need to overhaul that again.

Rinse and repeat. Eventually, you're growing through acquisitions, product expansion, and talking about $10M monthly sales targets. And each of these things will fundamentally break how your organisation works.

Why point this out? Because it's important to realise that many problems are the direct result of success in other areas. You need to solve these problems. But you also need to learn to live with them. Because there will always be problems. Something will always be broken in your growth funnel. So learning to enjoy the journey and persevere is essential.

Additionally, it's useful to predict future problems. If you know that outbound sales will not scale to your quarterly growth goals in a years time, you should think about what new functions, people, products, and ways of working you will require, and start to invest now. If you're expecting explosive growth in one part of the funnel, there's a good chance the next stage will need an overhaul. When setbacks are expected, you can prepare for them, and reduce the negative impact.

Many founders burn out because they're always praying for the problems to finally ease. And, sure, you will occasionally experience short periods where things seem to be going well. But it's always only a matter of time before your success leads to more challenges. This is the way. The most investable and likely to succeed founders are those who, either naturally or through personal development, can soldier on and even enjoy this process. Because it is fun! Especially when you learn to not take things personally, and accept setbacks as a central component of building something great.

Tags: advice, startups, strategy

# Building a committed, motivated team

Corporations invest in employee experience because, to get things done, they need workers, good workers are difficult to recruit, and unhappy workers leave. All this is true for startups, too. Unfortunately, startups are resource poor, and cannot invest nearly as much in salaries, perks and career development. 

**So what can startups do to retain great employees?**

The most important thing is to hire the right people in the first place. Workers have diverse motivations and values, and when you hire someone with desires you cannot satisfy, you’ll expend significant energy placating them. No matter what you try, they’ll eventually leave, feeling cheated due to poorly managed expectations. Instead, startups need to hire people who define success the same way the startup does. Working in a startup is extremely fulfilling and fun for some people, and awful for others.

- Only hire someone primarily motivated by money if you can give that to them. A salesperson motivated by money will thrive under an uncapped commission plan. An engineer who you can only afford to pay at market or below will never feel satisfied. 
- Some people are motivated by career growth and want to lead a team. They often have a timeline in mind for this career move. Never hire these people as individual contributors if there is no line of sight for them to achieve this. 
- If someone is motivated by career development and training, only hire them if you actually have time to provide this. Otherwise, it’s better to hire someone more experienced. 
- Never hire someone who would rather slowly produce quality than quickly produce results. These people belong in a more established company. 

When an early stage employee can satisfy their own needs by simply succeeding in their role, you’ll achieve better results with less management overhead. When an employee needs more than you can give them, they will distract you from focusing on the most important things.

The most important thing to hire for is *startup metabolism*. Some people just move more quickly than others, have a high tolerance for stress and whiplash, and are desperate to prove themselves. Others are self assured, meticulous, and sensitive to stress, risk, and disorder. These people belong in bigger companies. 

The ideal startup employee knows enough to do their job without training or handholding, but is still hungry to prove themselves. These people will [work smart and hard](/post/startups-must-work-smart-and-hard/). They’ll mostly motivate themselves. 

Your goal as a leader is to create a fulfilling work environment. Not a [pleasant, easy, orderly, low stress one](/post/great-startups-lean-into-chaos/). Being honest about that will help you to build a high performance, low management overhead team.

Tags: advice, startups, people

# Disrupt and defend with platform envelopment

It can be difficult to convince a customer to adopt your product when they already have a solution they're happy with. This is why disruptive products typically need to be radically better, radically cheaper, or both. However, thanks to platform envelopment, it's actually possible for a notably worse app to disrupt superior incumbents. 

To pull this off, a startup first builds something adjacent to the product they wish to disrupt. This needs to be something they can sell to the same customers, but something that will be easier to sell than a directly competitive product. Next, you add the features you want to disrupt, and convince your new customers to switch over from the incumbent. 

For example, if you wish to disrupt a payment provider like Stripe for SaaS companies, you could build a subscription management system first. If you want to disrupt a dominant subscription management system, you could build a subscription analytics tool.

This method of challenging incumbents works because in the short term, it makes it easier to get your foot in the door with your target market, and in the long term, it makes it easier for you to create something that is radically better (through first honing your skills in a less competitive/defensive market) or radically cheaper (through bundling).

Platform envelopment is actually the primary way that incumbents try to kill startups! Microsoft Teams did this to Slack and Instagram to Snapchat. So, you can think of this as using their tools against them. This strategy is so common for incumbents because they typically don't need to first identify a breakthrough market — they most likely already have access to the target customer.

## Advice for incumbents 

If you have territory to defend, it's crucial to pay attention to what new products your customers are adopting, and consider how they could expand their functionality to gradually erode your moat. Most disruptive products will approach from the side, not the front. That is to say, they will enter your market through an adjacent use case, not a direct challenge to your core value proposition. This means hubristic companies will ignore the threat until it is too late. Envelope them before they envelope you.

Companies must understand their strengths and weaknesses. As an incumbent, you probably can't move as quickly as a startup, because you have more process and less risk tolerance. But, you can parallelise work, you have easy access to the market, and you have existing product foundations to lean on.

## Advice for startups

If you're on the offensive, you need to choose the right wedge. What smaller problem can you solve that will make the people who buy your competitors products absolutely love and trust you? It'll be a risky move when they eventually switch from an incumbent's product to yours, so you'll need to have a great relationship by then. Ideally, your wedge product should have the exact same buyer persona as the product you'll expand into.

Take advantage of complacency: avoid appearing as a threat until you really need to, keep your plans to expand close to your chest. It can even be beneficial to integrate with the incumbents. This will make your product more compelling in the early days, as it will play nicely with the existing ecosystem, and also provide a seamless migration path when customers eventually choose to switch.

Tags: advice, startups, strategy

# Great startups lean into chaos

Most managers in early-stage startups think that chaos is inversely correlated with results. That is, they think that chaos breeds bad results and an unhealthy environment, while order breeds good results and a more harmonious environment. This perception is wrong.

## Order does not necessarily breed success

Some problems require structured problem solving while others require more chaotic creativity. Many problems can be solved with either approach. So, both order and chaos can lead to success.

Problems with one true answer, that is difficult to find, require a process to solve. For example: Will this very expensive technology solve our problem? Is a specific new technology likely to disrupt our current approach? These are problems where the cost of being wrong is massive compared with the cost of delay. Few problems are like this.

Problems with many good enough answers can be more quickly answered through chaos/creativity/decisiveness than process/order. For example: What is a good startup idea? Where should we locate our Australian office? What is the right price for our first product? These are problems where the cost of being wrong is minimal compared to the cost of delay. Most problems are like this.

A company that quickly answers many questions in a good enough fashion will almost always out perform a company that answers fewer questions, more slowly, in a more excellent or correct fashion. 

## Chaos need not create pain

Most people find chaotic work environments difficult. They want to know where they stand, what their goals will be next year, when they'll get their next promotion, whether they'll need to travel to the event next week. This is why chaos is perceived as  correlated with having a bad time at work. But, these people are unsuited to work in most roles at an early-stage startup.

People who thrive on chaos are difficult, but possible, to find. These people will deliver the best results to most early-stage startups. They have a stoic response to setbacks and are comfortable taking risks in their decision making. They will enjoy themselves along the way, too.

This is why the people who get you from $0-20M are rarely the people who will get you from $20-100M — large companies legitimately do require more order and process to work[^1][^2], and this means having a very different employee base[^3]. 

## Success breeds chaos

Success and chaos are in fact correlated, just in the opposite direction to what many people believe: success *creates* chaos.

This is actually pretty obvious when you think about it. Growing ARR by 5% each month does not create much pain. Growing ARR by 250% in a single month does. This will stretch your existing resources thin.

So, radical success guarantees radical chaos, another reason why your team needs to be built for chaos.

## The cost of optimising for order

All early-stage startups are chaotic, so when a startup starts to fail, this is usually blamed on the chaos. This leads to a massive amount of energy being invested in creating order through process and scaling the team. This pivot to order is almost always a deadly distraction from the real reasons why the startup is failing.

This is why most startups stall somewhere between $1-10M ARR. A product with modest product-market fit can get to this level of revenue through brute force, but it will struggle to scale much beyond that. When growth stalls, these startups blame the chaos and focus on creating an orderly company instead. Two years later, they have successfully codified processes that do little to solve their true problem: they chose a market or problem that was too small, or their solution doesn't adequately solve their problem. The quickest way to solve those problems is almost always perseverance through the chaos, rather than a one-to-two year pause on real progress to instead make what is, for early-stage companies, mostly superficial progress (specifically: the transition into an orderly organisation).

[^1]: At some point, chaos does overwhelm the organisation, it just happens much later than most people think.
[^2]: This is also why you should be cautious when hiring people into an early-stage startup, especially managers, who only have mature startup experience. They tend to think: "my last company was orderly and we achieved great results, this company is chaotic and struggling, therefore I should invest in making this company orderly".
[^3]: Of course, some people can handle both ways of working and will join you for the whole journey.

Tags: advice, startups, operations, strategy

# Salespeople need decisive decision makers

If your startup has salespeople who sell directly to businesses, they’re probably wasting a lot of time talking to people who cannot make a decision. 

People who can’t make a decision to buy include employees or managers without the authority to buy, or CEOs/founders who lack decisiveness.

If you can quickly determine who can and cannot make a decision to buy, you will dramatically improve your sales momentum. The best way to do this is to ask your prospect questions like:

- What steps are required to close this deal?
- Tell me about the most recent SaaS purchase your team made. What was the process like?
- Who’s approval do you need to buy a product like ours?

Most contacts will give you a useful answer to these questions. Though, keep in mind two things

## Dealing with indecision

Indecision comes in many forms, but some are more common than others. Here are a few specific examples:

- **Employees or managers without the authority to buy.** You should upgrade your contact as soon as possible. Find out who can decide, and get access to them. Do not rely on your contact to sell up to whoever the real decision maker is — they will never be as good at this as you are. Think about how long it takes for a new salesperson in your company to learn how to successfully sell your product. In my experience, deals with decision maker access are 3x more likely to close, so if you can’t get access, move onto the next deal.
- **The CEO who can’t decide.** While the best leaders are decisive, many leaders are not. Typically, they’ll delegate decisions downwards and rely on organisational consensus to make decisions. In many cases, it’s best to abandon these deals, but it is also possible to apply the same principles we just covered: upgrade your contact. If someone lower in the organisational hierarchy is truly empowered to decide, get access to that person and pitch first-hand.
- **The inflated manager.** This one is tough to identify, but middle managers in many organisations do not have buying power, and yet will tell you that they do. This is as common as it is frustrating. These people will often gate keep the true decision makers as it makes them seem less influential if they do defer to them. It’s usually best to move on.
- **The manager with no (time or money) budget.** There’s nothing more frustrating than getting to the finish line only to find out you need to wait for budget renewal in two months. Ask: “assuming we tick every box and you’re excited to move ahead, how soon can we get started?” This also applies to people bound by existing vendor lock-in. Some middle managers have small discretionary budgets: it's possible to use these to your advantage. For example, if your product delivers results quickly, and you can offer a trial at a price that fits within their discretionary budget, you may be better positioned to sell to the real decision makers after you've delivered some real results to the client.

The best salespeople have great intuitions for which prospects are most decisive, and how to get access to better contacts. Everyone else wastes their time talking to people who will never buy, no matter how appealing they make it sound.

Tags: advice, startups, sales

# Startups must work smart and hard

Strategy is a dirty word in early-stage companies. It's easier to over-plan than under-plan. Over-planning leads to inaction, which is antithetical to startup growth. However, working smart is important. No matter how loose your plan is, it needs to be correct enough to push you in a direction that will lead to results. Startups are resource-poor and idea-rich. When you can only work on 10% of the things you know you need to do, prioritisation is crucial, and even the simplest act of prioritisation, no matter how intuition-driven it is, is an act of strategy.

Working smart is not enough, though. Startups need to work smart and work hard. This is why startups fail: they require unbelievable perseverance. It is excruciating to create product-market fit. It's even more painful to build a repeatable growth model. And no matter how hard you work, if you make bad decisions, you will fail anyway.

Every startup is under constant threat of being strangled in the cradle by incumbents. By now, large companies are aware of the constant threat of disruption by startups. All great tech companies won by overcoming their Goliaths. So, they themselves look for budding success stories and kill them with impunity.

Established players have massive advantages over startups. "What's stopping Google, Microsoft, or Apple from doing this?" — virtually every VC-backed founder has answered this question innumerable times. It's a fair enough question:

- Incumbents have privileged access to customers, vendors, and partners. While they still need to go through the painful process of finding product-market fit, it's much easier for them to build a repeatable growth model.
- Entrenched network effects grant them difficult-to-penetrate moats.
- Large companies can afford, and already employ, the best talent in all relevant fields.
- Large companies can tolerate a degree of failure, allowing them to invest in many seemingly unrelated bets.
- Big Tech and corporate tech companies have massive teams that they can throw at a problem, winning through sheer brute force.

Startups can almost never compete on any of these fronts, so to win, they must lean into their unique strengths — strengths that massive companies cannot replicate.

Large companies don't typically work very hard. They win through parallelised effort. The combined effort of a massive workforce of smart, but only moderately engaged employees[^eric-schmidt], accumulates into massive output. Startups are the opposite. In many early-stage startups, a single engineer accounts for 25–50% of the total output of the company. It is incredibly important for this person to be engaged and work very, very hard.

The unique advantages of small companies are:

- **Nimbleness.** It is easy to change directions when new learnings emerge.
- **Dedication.** It's easier for employees to dedicate themselves to a cause shared by a small group than to a top-down strategy from corporate management.
- **Low communication overheads.** Every new employee exponentially increases the number of relationships and conversations involved in getting anything done. Small teams can easily broadcast decisions and focus on execution.
- **Limited baggage.** Nothing should be sacred in any startup. If a change in direction requires a painful pivot that will bruise egos or break existing business models, great startups forge ahead regardless. Corporations are restricted by path dependency.
- **Risk appetite.** Startups can break rules fearlessly, with little concern for public relations, internal pushback, or contractual conflict.

To win, startups need to lean into each of these advantages because they're a decade away from the kinds of moats enjoyed by established corporations[^remote]. This means they need to work smart (*i.e.,* mostly do the right things) and work hard (*i.e.,* execute at a pace and with intense risk tolerance). Remember: Goliath wins 99% of the time.

[^eric-schmidt]: Recently, Eric Schmidt caught flack for saying that "Google decided that work-life balance was more important than winning," and this is why startups like OpenAI may disrupt them. Despite walking back these comments, Schmidt was correct. Every company decides how "startup" it wants to be. The reality is that every perk you offer subconsciously indicates to your team that this is a "rest-and-vest" environment, not a high-stakes startup. Making this transition can be beneficial, especially for aggregating talent, but it's a tradeoff that makes it difficult to be nimble.
[^remote]: What about remote work? It's possible to lean into these advantages while working remotely, but it's much more difficult. This is why companies still creating product-market fit and a repeatable growth model should generally colocate.

Tags: advice, startups, strategy

# Hire salespeople in pairs

Startups should try to hire salespeople in pairs. This is particularly important when spinning up a new channel (*e.g.,* launching in a new market, opening up a partner channel, or kicking off outbound sales). Hiring in pairs is helpful for a number of reasons:

First, knowing if a new sales recruit will succeed is difficult. Even salespeople with fantastic experience are unsuited to sell certain products in certain markets. Hiring the wrong person can be a serious setback when it takes a month to find out if they can do it, a month to recruit a replacement, and another month to find out if your second hire will make it. If you hire two people, you have a greater chance of landing at least one effective salesperson.

Second, when trying something new, like launching in a new market, opening up a partner channel, or kicking off outbound sales, it's hard to know what your salespeople should achieve because there are factors outside of their capability that impact sales results. Suppose you hire one person to launch your product in a new geography, and they fail to deliver results that match your success in your initial geography. Many leaders will blame and replace the salesperson, only to fail again because the problem wasn't the salesperson. In these situations, problems with the product, economic or cultural differences between your old and new markets, pricing, or other variables could cause poor traction in a new geography. When you hire two people, you can compare their results and, therefore, more clearly see whether traction challenges are people-related or otherwise. 

Third, competition fuels sales performance. Salespeople notice when their peers book more meetings, close more deals, and earn more money than them. A lone salesperson is almost always less motivated than one with a competitive peer.

Tags: advice, startups, sales

# One way for OpenAI to build a moat with developers

OpenAI as an API provider is easy to replace with another service like Google's, so most developers (and even users) regularly switch LLM providers as new capabilities emerge, and prices change. So far, there doesn't appear to be any moat for any of these models.

OpenAI should try to establish commercial and network effect moats as aggressively as possible to compensate for this (while of course not giving up on building capability and cost advantage moats).

One could argue they already have this in consumer: many people think of ChatGPT immediately when they think of "AI" and this may persist long term.

To establish this in B2B, OpenAI should try to convert this consumer "mindshare moat" into a B2B moat. I can think of one way to do this.

First, create a "log-in with ChatGPT" SSO service, akin to sign-in with Google, Apple, Facebook, etc.

Second, allow developers to consume their user's token allowances from their paid ChatGPT plans.

This is a similar model to Apple's "run the model on-device and you don't need to pay anything to add AI to your app" strategy. "Use OpenAI for authentication, and you can pass GPT API costs onto the user".

This would be an intense incentive for developers to build on OpenAI. I think most B2B SaaS apps that wish to add a layer of AI to their products would go down this route, rather than watch their gross margins gradually compress over time.

Tags: advice, startups, misc

# Understanding tacit knowledge

Startups contain a lot of knowledge. While it's easy to document knowledge like product specifications, customer profiles, pricing, and processes, some organisational knowledge is difficult to write down and, therefore, goes under appreciated. We call this tacit knowledge.

Tacit knowledge is unwritten, unspoken, and often unconscious knowledge. One's individual experiences and intuitions form the basis of tacit knowledge. When thanks to their experience, someone handles a situation effectively without knowing how to clearly explain their process, this is thanks to this unconscious knowledge.

As great as it would be to solve all problems with clearly defined processes and documented knowledge[^documentation-101], the reality is that most organisational knowledge tends to be tacit. So, companies should factor this into their ways of working. Research has demonstrated the value of tacit knowledge in organisations in two ways. First, by measuring the impact of knowledgeable employees leaving the organisation[^tacit-retention] (we've all experienced this first hand). Second, by showing the effectiveness of various methods for encouraging tacit knowledge development[^tacit-impact]. This latter point is good news for startup leaders because it tells us that, while it may be difficult to write down this type of information, it's still possible to encourage it to spread.

Tacit knowledge is not easily shared or articulated, as it often requires personal contact, regular interaction, and trust to effectively transfer from one person to another. So, the best way to spread it is to encourage personal contact and regular interaction and to build trust within teams.

First, teams should tackle work in groups. Engineers should participate in pair programming. Salespeople should listen in on each other's calls. Customer service agents should tackle tickets in pairs. Coupling new recruits with experienced employees is especially important for tacit knowledge transfer, so include this practice in your employee onboarding process.

Second, teams should share their work with others. Engineers should demonstrate what they've built and explain the decisions they made along the way. Salespeople should demonstrate how they won their deals. All-hands meetings are a great forum for this type of knowledge sharing.

Third, encourage cross-functional collaboration. Time with an engineer will teach a support agent why the product works as it does. Time with a salesperson will teach an engineer what customers care about. Many startups go too far to insulate teams from internal distractors. While you don't want teams constantly harassing each other when they could solve problems independently, you also don't want silos. Pay attention, and you may realise some of the best performers are employees with good relationships outside their immediate team.

Fourth, hire for tacit knowledge. People with experience in similar businesses targeting the same customer profile will likely come with valuable tacit knowledge. If you find someone with fantastic tacit knowledge that enables them to ramp up quickly in their new role, hire some of their former colleagues.

Lastly, get your hands dirty as a leader. In the early days of a startup, even founders can lack the depth of tacit knowledge required to succeed. First-hand experience selling, supporting and designing your product will build the type of knowledge you'll later need to transfer to others.

Because people learn tacit knowledge by osmosis, the methods above are especially beneficial for remote teams. A lack of tacit knowledge transfer may partially explain why some studies report that remote work leads to fewer innovations[^remote-innovation] despite delivering greater productivity[^remote-productivity]. If your team works remotely[^remote-advice], ensure that time spent together maximises the type of collaborative activities outlined above.

[^documentation-101]: Don't use the existence of tacit knowledge as an excuse to avoid documentation. [A lot of knowledge can and should be documented](/post/product-documentation-101-for-startups).
[^remote-advice]: I recommend very early-stage startups co-locate wherever possible and transition to remote-first after achieving product-market fit (if they wish to). In my opinion, mature startups suffer less from the downsides and get more value from the upsides of remote work.
[^tacit-impact]: Rajendran Muthuveloo (2017): "The impact of tacit knowledge management on organizational performance." Published online by [ScienceDirect](/links/724747523/).
[^tacit-retention]: Abdullah Gaghman (2020): "The Impact of Knowledge Behavioural Factors on Tacit Knowledge Retention." Published online by [Knowledge E](/links/724748542/).
[^remote-productivity]: Nick Bloom (2023): "Does working from home damage productivity?." Published online by [The Hill](/links/655271956).
[^remote-innovation]: Yiling Lin (2023): "Remote Collaboration Fuses Fewer Breakthrough Ideas." Published online by [arXiv](/links/669316459/).

Tags: advice, startups, operations

# Australia to quash angel investing

In the early days of a new startup, money is tight. Before they raise their first serious tranche of venture capital, most startups get by on the personal savings of their founders, cloud credits, and a small amount of pre-seed funding. This pre-seed funding can come from family, friends, industry veterans who've turned to angel investing, and established venture capitalists. I consistently hear from founders that, of all of these sources of very early-stage capital, angel investors add the most value.

While an angel investor may not bring much capital, a little can go a long way in the early days of startup building. More importantly, though, angel investors bring a wealth of experience and connections that can dramatically accelerate the trajectory of the startups they work with. Wise founders recruit angel investors who can offer them differentiated assistance. For example, a founder building a cybersecurity startup will typically recruit angel investors with experience building and selling cybersecurity products. These investors make introductions to recruits and customers and help to solve business problems as they arise. 

Some startups get this type of help from consultants, but consultants can be prohibitively expensive for small startups. Angel investors have skin in the game by owning a share of the startups they work with. They are, therefore, motivated to help their portfolio companies succeed without consulting fees.

This arrangement is not only great for startups but also for angel investors because this type of investing is one of the best ways for technologists to build wealth. Most angel investors have a day job in more mature technology companies. They see investing as a way to support founders within their network, create additional value in the world, and build personal wealth. They can own a small piece of a company that they believe will be big one day for a relatively small amount of money. Often, these companies don't survive. But when they do, liquidity events like acquisitions, secondary share sales, and IPOs can be life-changing.

To anyone outside the tech industry, founders and VCs get the most attention. However, angel investors play an indispensable role in the early days of many world-changing startups. While many VCs allocate capital and otherwise play a predominantly passive role in the building process, angel investors can be incredibly hands-on. 

I'm incredibly disappointed to learn that, in an effort to protect consumers from predatory investment products, the Australian Government is about to make it nearly impossible for successful startup workers to reinvest their earnings into new startups. Specifically, the Australian Financial Review reported yesterday that the Government is considering a change to the definition of a so-called *sophisticated investor* to $4.5 million in net assets or $450,000 in gross income[^investor-changes].

Given that many angel investments today require *sophisticated investor* status and most active angel investors in Australia do not meet the reported criteria, this will essentially outlaw an enormous chunk of all angel investing activity.

This regime will be bad for startups and, in turn, the Australian economy. Less available capital means less startup formation. Less access to angel investors means fewer startups will succeed.

This regime will lock startup workers out of their best opportunities to build wealth by eliminating their eligibility to invest in startups. These people are not stupid. They do not need paternalistic government protection. Under the new criteria, a startup CTO earning $400,000 a year, with a net worth of $4 million, will not be allowed to invest $10,000 into a venture founded by people they know and trust, in a market they know like the back of their hand. 

While the Australian Government may be justified in its desire to protect investors[^why], it should balance this desire against the negative consequences of any proposed policy change. If the Government is serious about creating a thriving startup economy in Australia, it should instead move in the opposite direction. The current criteria for *sophisticated investor* status, defined as having earnings above $250,000 or $2.5 million in net assets, unnecessarily locks many potentially great angel investors out of some of their best opportunities to create value for society and wealth for their families. The status quo already drives our best workers overseas for better work opportunities. This change will only further hollow out the domestic technology market.

[^investor-changes]: Michael Read (2024): "Labor to overhaul 'sophisticated investor' test." Published online by [The Australian Financial Review](https://fastertim.es/links/714121782/).
[^why]: The Australian Government's motivation for the change appears to be driven by concerns about retirees losing their savings in complex investments they don't fully understand. We could, instead, implement more surgical regulations to help with this problem without harming innovation.

Tags: advice, startups, society

# Stepping on toes

When each independent team works effectively, a company can solve any remaining problem through collaboration between teams. An organisation where teams and individuals are constantly concerned with issues in other teams, to the detriment of their responsibilities, descends into ineffective chaos. Realistically, most startups exist somewhere on a spectrum between these two states, with some teams who work effectively and others who consistently mishandle their responsibilities.

This uneven distribution of competence commonly challenges startup leaders and individual contributors because for one team to succeed, another typically needs to have their house in order. In small companies especially, teams tend to work downstream of other teams and are therefore highly impacted by their coworkers down the hall. For example, life for a support team can be comfortable or arduous, depending on the quality of the product they support. Sales teams can live and die by the quality of the leads they receive from their colleagues in marketing. Product teams depend on customer success teams to manage customer expectations. Engineering teams depend on product teams for product strategy. Individual contributors depend on leaders for direction.

So, how much should competent people, confidently managing their responsibilities, meddle in the affairs of other teams they perceive to be dropping the ball?

Conventional career advice is for individuals to focus primarily on their areas of ownership. Getting too invested in resolving problems you ultimately cannot control is a recipe for unnecessary stress and can sour an otherwise enjoyable job. Stephen Covey famously articulates this in his book, *The 7 Habits of Highly Effective People*, outlining three buckets for problems in business and life more generally:

- __Things you can control are where you should invest most of your energy. It's healthy to stress about these things because you have the agency to improve them.__

  For example, engineers can control how they break down a coding task. They can independently try something new if they feel their current approach could be more productive.

- __Things that you can influence with collaboration and feedback are worth some of your time. While you may have less autonomy to resolve these problems independently, you can influence those who do, and therefore, it's OK to stress a little about these things.__

  For example, while an engineer might not choose which features their team will build next, they can collaborate with their team's leader or product manager to influence this decision.

- __Things you cannot control are not worth stressing about. Overthinking these things can cause unnecessary anxiety and strain.__

  For example, an engineer working on tax automation shouldn't fret over upcoming regulatory changes. Government-level changes are entirely out of their control, so they should focus on other things.

While this is sound advice, it's better suited to individuals in large organisations, where deeply entrenched processes, politics, and other organisational structures make it incredibly difficult to affect change in areas other than your own. In these organisations, if you try too hard to transform the organisation around you, you can inflict unnecessary stress on yourself and potentially sabotage your career. In startups, however, individuals have much more agency, and the best thing you can do for your career is to exercise this agency.

Startups are small teams. In a small team, each person accounts for a considerable share of the effort expended and responsibilities owned by the whole. When a big chunk of a small team fails, the team usually fails. In an early-stage startup, almost everything falls within every single person's circle of influence, if not control. So, most employees of an early-stage startup can affect change in any department if they try hard enough.

Not only is it possible for most employees of an early-stage startup to affect just about any type of change, but it's also crucial for career success. In a large enough organisation, you can progress your career despite your employer's challenges. In a startup, you only succeed as an individual if your startup succeeds. If you leave problems unresolved to avoid stepping on people's toes, your startup may fail. 

So, leaders and individual contributors should focus on their areas of ownership. Most of the time, in a startup, this is more than a full-time job anyway. However, for a startup to succeed, capable people must influence all parts of the business because failure in one team can be an existential threat to a small company. 

Employees of large organisations should be more conservative when assessing their circle of influence and control, if for no other reason than mental health. In a startup, however, assuming you have broad agency and influence is best. When startups win, it's thanks to people like this.

Tags: advice, startups, operations

# Processes make inexperienced people wiser, and experienced people dumber

Process can stop a salesperson from discounting a product below cost price, a professional services consultant from overpromising, or a software engineer from implementing a feature with security or privacy flaws. In these scenarios, a process is a tool to make inexperienced people behave like their more experienced colleagues. So, a process can be a sort of institutional knowledge that the business imbues on its team to ensure high-quality work and avoid painful mistakes.

But process can also do the opposite. When an individual is wiser than the processes they have to follow, they behave like a less experienced person. A salesperson who knows an aggressive discount today will lead to a sizeable expansion deal in just a few months loses their opportunity. A professional services person with an innovative idea that could dramatically expand their company's total addressable market cannot pitch this to an ideal early adopter. An engineer with an innovative and assuredly secure way to solve an urgent problem must wait for approvals to deploy their fix.

In a sense, each process is an equaliser: processes make everyone average. For a team that is skewed inexperienced, this elevates the team's overall capability. For a team with wiser constituents, it dumbs them down. Put more crassly, standardisation, in principle, makes some people dumber and other people smarter. Fortunately, I have some practical advice for startup leaders wrangling business operations.

First, hire great people. Startups are resource-poor, so every team member needs to be excellent. Sometimes, this means inexperienced people with fantastic natural capabilities. Sometimes, this means paying extra for experience. Either way, great people make fewer mistakes, removing the need for arduous processes.

Second, consider the impact and likelihood of a hypothetical mistake before implementing a process to avoid it[^1]. If something is unlikely to happen and is relatively low cost, there is no point in actively avoiding it beyond the basics of hiring good people and promoting common sense decision-making. If a mistake is likely and expensive, you may need a process to resolve it. Don't implement a process just because one person made a mistake once. If it's unlikely to happen again, it's not worth slowing the team down.

Third, you should focus your operational innovations on teams composed of inexperienced and entry-level roles. The average experience level of an engineering team is likely greater than that of a customer service team, which is likely greater than an outbound sales team. Given standardisation helps the inexperienced and hinders the experienced, teams with less experience should have more processes.

Fourth, empower leaders to break the rules. Even the most inexperienced team should have a wise and capable leader. So, when a team wants to breach a standard to deliver a greater outcome to the business, there should be a way. 

Finally, prune your processes. Mature organisations move slowly because of institutional baggage. Just as a dynamic and engaged parliament should repeal laws that no longer service the public[^2], operations teams and team leaders should regularly simplify the ways of working for their teams.

[^1]: In [**this article**](/post/stay-ambitious-with-the-help-of-experimentation/), I explain how startups should focus their research and experimentation on high-risk items where the cost of being wrong is significant. This article includes a graphic (`Figure 1`) which can also be used for determining whether a hypothetical mistake warrants a process. 
[^2]: To avoid bureaucratic calcification, [Texas automatically sunsets state departments after twelve years](https://brandon.uno/links/457685614/) if they are not renewed by the legislature.

Tags: advice, startups, operations

# Tackle hard problems to turn walls into moats

Some problems are too easy to solve: low barriers to entry result in a crowded market with many copycat products and low margins. Some problems are too hard to solve: insurmountable barriers to entry result in unfundable or failed startups that never get off the ground. 

For a startup to win, it needs to solve a big enough problem to be valuable and small enough to be solvable. However, it can't be too easy to solve; otherwise, competition will eat away at margins and increase sales costs.

Founders' appetite (and capability) to solve hard problems vary greatly. It's easier to make a small fortune with a B2B SaaS startup than to make life multi-planetary. Even within the B2B SaaS category, willingness to tackle difficult tasks varies greatly.

Many startup leaders shy away from the most painful problems. Whether it's too hard to build, too hard to sell, or requires massive scale to achieve viable economics, there are many reasons to put opportunities in the too-hard basket. Tackling difficult problems is how we build differentiation in startups, however.

Problems that feel too difficult to solve are often the problems we should run towards. When we tackle these problems, we turn walls into moats. Many of the problems you find scary today are the problems your competitors will soon struggle to follow your lead in solving. We build moats by giving it a go.

So, dig a little deeper next time an engineer tells you something is impossible to build, your head of sales tells you something will be too hard to sell, or your accountant tells you the unit economics won't work. Often, they'll be right. But if you take them at their word every time, you may miss your best opportunities to build a defensible moat. Startups are deploying Generation IV nuclear reactors, mining asteroids, and delivering goods with automated drones. These things make most problems in SaaS feel pretty beatable.

Tags: advice, startups, strategy

# Effective startup leaders cultivate soft power

Political scientist Joseph Nye's framework for soft and hard power provides a useful lens through which startup leaders can solve organisational problems. Nye defines hard power as authority and capacity for coercion (primarily military power) and soft power as one's capacity to persuade and influence (*e.g.,* cultural exports like Hollywood, Bollywood, and K-pop)[^1]. Let's explore how this idea applies to startups.

Hard power in startups is about authority and structure. When a leader or team exerts hard power, they pull rank and make something happen by fiat.

- Top-down strategy.
- Job descriptions/playbooks and organisational charts.
- Budgets.
- Performance reviews.
- KPIs.
- Action items after meetings.
- Processes, checklists, compliance tasks.
- Micromanagement.

Soft power in startups revolves around culture and influence. It's about shaping behaviour not through directives but through the company's ethos.

- Relationships within and between teams.
- Culturally/socially-enforced ways of working.
- Communication across teams (*e.g.,* proactive status updates, all-hands presentations) and stakeholder management.
- Company vision and values.
- Workshopping and collaboration.

Soft and hard power are both essential to startup success. When a startup leader depends too heavily on hard power, their team becomes fractious, disagreements between teams become unnecessarily heated, and employee experience degrades. When a startup leader depends too heavily on soft power, expectations become unclear, teams lose urgency, work becomes casual, and teams fail to achieve their desired outcomes.

Exertions of soft and hard power are both fueled by trust. But, while management through hard power can sometimes degrade trust, management through soft power tends to build trust. This relationship between soft and hard power, where using soft power increases one's future capacity for hard power, is why managers should rely on soft power wherever possible.

As a general rule of thumb, soft power increases collaboration and creativity, while hard power clarifies expectations and provides structure.

## Using soft power effectively

**It's not enough to set the strategy.** You need to sell it to your team and any teams you work with. Leaders should consider how their actions impact other teams and build trust with those teams through soft power relationship building and communication. Product teams, for example, are upstream from sales and support teams. To succeed, they must not only have an effective strategy; they need to win the support of these teams. When customer service or sales object to product strategy decisions, it's often a result of a lack of advocacy and communication on the part of product management. It may not reflect on the strategy itself. This same dynamic plays out within teams when individual contributors disagree with a strategy imposed on them by management.

**Leaders must win over influential people.** Within every organisation, there are people with outsized influence over the company culture. While these people are usually managers, they can also be tenured or trusted employees who tend to be particularly vocal. A leader who has won the support of these influential people can more effectively exert hard power without blowback.

**People over process and culture over rules.** Because using hard power can cause unnecessary friction, consider whether you need to impose a new rule or process on your team to solve a problem.

**Give people autonomy and accountability.** People want to be in control. Whenever someone is capable of owning something independently, let them[^2].

**Hire great people.** Great people don't require micromanagement or other hard power tactics to achieve great outcomes.

**Don't over-index on soft power.** Teams and employees need to understand what they must achieve to drive the business forward. Clear position descriptions, KPIs (especially for customer service and sales roles), and well-outlined initiatives empower individuals to achieve. Hard power only disempowers when it's unnecessary.

Every day, a great strategy fails in a startup because a leader underinvested in trust and relationship building or unnecessarily took autonomy away from individuals or a team. It's not enough to have a plan. You also need a team that is eager to execute. Only soft power can give you that.

[^1]: Nye, Joseph S., Jr. 2005. [Soft Power: The Means to Success in World Politics](https://wcfia.harvard.edu/publications/soft-power-means-success-world-politics).
[^2]: [How accountability enables autonomy](/post/how-accountability-enables-autonomy/).

Tags: advice, startups, people

# There are no “technical initiatives” — only ones you don’t understand

Many product development teams distinguish between technical and so-called product initiatives. Generally, these teams will consider product initiatives to be initiatives that deliver new features to customers. These same teams would define technical initiatives as any project that improves the technological foundations of the product but does not deliver customer value.

|         Product initiatives          |         Technical initiatives          |
|--------------------------------------|----------------------------------------|
| Expand email template library        | Optimise lists database                |
| Enable segmentation of contact lists | Rotate dispatch IPs for deliverability |
| Dashboard for mail analytics         | Move caching to redis                  |
| Drag-and-drop editor                 | Centralise error logs                  |
| Spam-score reporting                 | Migrate containers to AWS              |

This distinction is often a problem for teams. In a company where product management has more influence over the roadmap, teams become feature factories, and teams neglect technical maintenance or improvements. In a team where engineers hold the power, teams might constantly refactor and upgrade technology without delivering much customer value.

Product and engineering leaders tend to see this as a prioritisation problem. If they allocated more capacity to neglected work, they'd solve the problem. This diagnosis of the problem is incorrect, though. 

The real reason why most teams neglect important work is that decision-makers have a poor understanding of the value of the work they are neglecting. 

Product managers with a poor understanding of the technical details of the product they manage will do one of two things:

1. Undervalue and therefore fail to prioritise important technical work they do not understand.
2. Defer to others, allocating some capacity to more technical people, who may prioritise or advocate for work at their discretion.

Technical leaders with a poor understanding of customer needs will behave similarly. They will:

1. Undervalue and therefore fail to prioritise important feature work they do not understand.
2. Defer to others, allocating some capacity to more customer-facing people, who may prioritise or advocate for work at their discretion.

Both options lead to bad results because great strategy comes from a holistic understanding of value, cost, and risk. The better solution for both parties is to build an understanding and appreciation for initiatives beyond their expertise because the distinction between product and technology initiatives does not exist. This distinction is an illusion caused by a lack of understanding.

When deciding what a team should work on, whether an initiative feels more like a feature or a technical improvement should not be a factor. The distinction between product and technical work occurs when we don't understand the value and cost of doing something and the cost of not doing it at all.

So, to prioritise work, we need to understand:

- Value — how much will we benefit from doing this work?
- Cost — how much will it cost us to do this work?
- Opportunity cost — what is the cost of not doing this work?

When deciding whether to tackle one of two potential product initiatives, product managers consider each of these properties (whether explicit or implicit in their process). Which feature will deliver more customer value? Which feature will cost less to do? What type of return on investment does the ratio of value and effort give us? What is the cost of delaying other initiatives?

Technical leaders ask the same questions when weighing their options between various technical initiatives. Which improvement will most lower our maintenance burden, decrease costs, or improve reliability? Which improvement will cost less to do? What return on investment does the ratio of value to effort give us? What is the cost of delaying (i.e., technical risk) other initiatives?

When you understand and appreciate the value and effort dynamics of all initiatives, whether they feel more technical or product-focused, it becomes easy to prioritise them within the same backlog. The motivation to prioritise this work in separate queues only occurs when the people doing the prioritisation lack this understanding and appreciation.

## Practical advice for startup leaders

First, whoever is accountable for product strategy needs to understand customer needs and the technical dynamics of the products they manage. This principle means that more complex, back-end heavy services and products require more technical product managers.

Second, engineers need a deep understanding of customer needs. The more you expose engineers to customers and customer feedback, the more they will appreciate the value of product work relative to technical work.

Third, great strategy comes from a deep partnership between product strategists and engineers. Each side of this partnership should constantly challenge the other and make no major decision by delegation. Instead, collaborate until both sides understand the value and costs associated with the decision. Even teams with experienced product managers need trustworthy technical leaders engaged in the strategy process.

Fourth, if you can't articulate the customer value of a so-called technical initiative, you don't understand it deeply enough and need to keep digging. There is customer value in every initiative worth doing. Customers want software that frequently improves, so a technical initiative to improve developer experience is valuable to customers. Customers want reliable software, so a technical initiative that improves service uptime is valuable to customers. Customers want to get their work done quickly, so work to improve the performance of services is valuable to customers. Customers want affordable solutions to their problems and vendors who are profitable enough to serve them forever, so initiatives that reduce hosting costs are valuable to customers.

Finally, the better you quantify how each initiative impacts the above, the better outcomes you will deliver. Teams should apply the same scrutiny and outcome-centric mindset to technical work as any other work.

Tags: advice, startups, technology

# Rediscovering progress

## Why it's time to revive the Y2K spirit

We're entering an exhilarating period of technological development, but most of us haven't noticed. Grim expectations for the future pervade despite our progress towards solving many of our most worrying problems and overwhelming improvements to quality of life. Recently, we've seen tremendous progress in biotech, green technology, and artificial intelligence. We need to update our worldview to match today's reality because returning to Y2K-era optimism is crucial for us to continue building technological momentum.

Supply may no longer be a problem for organ transplants and blood transfusions. Doctors have recently successfully transplanted genetically modified porcine hearts into humans[^nature-xenohearts], conducted blood transfusions with lab-grown blood[^bbc-lab-grown-blood], and engineered and implanted artificial bioreactor kidneys[^uc-artificial-kidneys].

A cure for cancer is finally within reach. New treatments have dramatically reduced the risk of death for various types of cancer[^guardian-lung-cancer-pill][^um-sound-wave-cancer], supply chain innovations are making treatments more accessible[^nature-anti-cancer-drug], and mRNA technology used for SARS-COV-2 vaccines applies to vaccines for multiple types of cancer[^nature-cancer-vaccines].

Speaking of vaccines, mRNA vaccine technology has empowered us to develop vaccines against holy-grail viruses like Malaria and HIV, as well as left-field conditions like fentanyl[^uh-fentanyl-vaccine] and meth[^tf-vaccine-meth] addiction.

Thanks to AI and synthetic antibiotics[^sa-ai-antibiotics][^bbc-antibiotic][^lancet-antibiotic], we may be on the cusp of solving antibiotic resistance, frequently touted as one of the most significant risks to humanity, with multiple solutions currently in testing.

Wearables and artificial intelligence enable new types of diagnosis and treatment. Smartwatches can diagnose Parkinson's disease up to seven years before traditional diagnosis[^ieee-smartwatch-diagnosis], warn wearers of cardiac emergencies, and monitor your sleep to treat PTSD-triggered nightmares[^pm-smartwatch-ptsd]. With AI, we can predict viruses' infectivity and variant evolution[^nature-ai-virus-prediction], empowering us to better respond to future pandemics.

There's a lot more on the health and biology front. Semaglutide seems to be a silver bullet in the obesity epidemic (and may be an effective treatment for other types of addiction[^atlantic-ozenpic]); electronic bandages can quickly heal grievous wounds[^ieee-electronic-bandages]; with new developments in Yamanaka factors[^aging-yamanaka], we may even be on the cusp of reversing ageing in humans.

We've also made massive progress in the development of green technology. The price of solar modules has declined by 99.6% since 1976[^wid-solar-cost-decline], dramatically changing the economics of solar as a power source. New battery technology promises to deliver batteries, a crucial commodity for a carbon-neutral grid, without rare-earth minerals[^mit-iron-batteries].

Desalination is now as cheap as US tap water[^neuro-desalination], a significant step towards solving our fresh water supply constraints. Continued progress here will enable incredibly ambitious desert greening projects. The Kubuqi Desert is already one-third re-greened[^time-greening-desert].

We have technology to manufacture emission-free steel[^bloomberg-clean-steel], manufacture cement with 90% reduced emissions[^mit-clean-concrete], and reduce air conditioning emissions by 60%[^mit-aircon]. Companies are using the technology behind fracking for oil and gas to generate geothermal energy virtually anywhere — not just in places with natural reserves[^mit-geothermal].

We finally have commercially viable carbon capture projects[^nyt-carbon-capture], and gene-edited trees promise to capture more carbon than their organic ancestors[^hit-co2-trees].

With modern semiconductor technology, we finally have nanotechnology and manufacturing[^brookings-euv]. Transistors on Apple's new iPhone are twelve atoms wide. Continued progress in semiconductor technology has enabled our recent AI revolution, dramatically making knowledge work, like programming, more effective. Soon, everyone with a smartphone will have access to a world-class doctor[^arxiv-gpt-doctor][^gt-gpt-doctor], lawyer, therapist, and a previously unfathomable wealth of general knowledge.

Supersonic jets are coming back[^aviation-supersonic-jets]. Truly wireless power transfer is a reality[^wired-wireless-power]. We're starting to understand the languages of whales, bats, and birds[^nyt-talking-to-animals]. We're preparing to mine asteroids[^astroforge-mining][^nasa-asteroid]. We're returning to the moon, and then we'll be on Mars. There are ambitious plans to tap Yellowstone to harvest energy and stop a future volcanic eruption[^sd-volcanic-energy].

If you pay attention to the research, it's undeniable that, despite our political problems, we're in an era of technological acceleration. After years of stagnation, where information technology monopolised technological progress, we're finally seeing progress in the physical world. And AI promises sustained digital progress. In the meantime, global poverty has continued to plummet. This improvement is primarily due to deploying and optimising existing technology, not new technology. The fact that, in an era of relative stagnation, we've managed to improve the well-being of vast swathes of humanity dramatically means we should be incredibly excited about what this new era of progress will bring.

But we are not excited. Most people seem to believe that the world is in decline. Surveys show that people generally think that global poverty and child mortality are worsening when both are improving. Americans are generally pessimistic about the future. Majorities believe living standards will decline over the following decades[^owid-optimism-and-pessimism-2018], the environment will deteriorate dramatically[^pew-environment-pessimism-2019], and automation and AI will be a harmful force[^pew-environment-pessimism-2019]. Only three percent of Australians believe the world is getting better[^owid-optimism-and-pessimism-2018]. Fifteen percent of non-parent Americans cite the state of the world and climate as reasons for not having children[^pew-non-parent-adults].

We weren't always so pessimistic about progress, the future, and technology. But it has been a long time. Two decades ago, at the turn of the millennium, people were overwhelmingly optimistic about the future. Surveys show that despite a clear-eyed perspective on risks like epidemics, terrorism, natural disasters, and climate change, over 80% of Americans were optimistic about the future and attributed their optimism to technology[^pew-optimism-1999]. In the Y2K era, virtually everyone valued technological innovation[^pew-technology-1999] and economic development and anticipated a high-tech protopian future.

Attitudes changed after the tragedy of 9/11. By 2002, majorities in most nations felt the world was becoming a worse place and were unhappy with national conditions[^pew-dissatisfaction-2002]. By 2006, seventy percent of people expected quality of life to worsen or stagnate for the next generation of Americans[^pew-pessimism-2006]. Global pessimism surged after 9/11[^gallup-optimism-2020], and the global financial crisis and climate change panic exacerbated the negativity. In the US, trust in government has plummeted since the new millennium[^pew-gov-trust-1999], achieving new lows after COVID-19.

There is a cost to pessimism. Appreciation for our progress directly correlates with optimism for the future. People who obsess over the challenges of the last two decades tend to have negative outlooks for the future[^owid-optimism-and-pessimism-2018]. For some, this can be motivating. For most, it's incredibly demotivating. This motion is a vicious cycle: motivation is perhaps the most crucial resource in the face of legitimate challenges like climate change or the return of imperial conquest. So pessimism demotivates us, breeds inaction, and worsens the problems causing our pessimism. Add this to the fact that we're unaware of the many areas where our pessimism is entirely misguided and that online and social media tend to trend towards the negative. You've got a global psychological funk that is tough to escape.

Anyone who has faced a seemingly insurmountable challenge in their personal life or career knows how difficult it can be to overcome a spiral of demotivation. It's especially hard when much of what you hear from those around you, from friends to trusted institutions, is overwhelmingly negative. Much of the world is collectively going through this right now.

The new millennium promised us technological solutions to all of our problems. Instead, it gave us terrorism, war, a climate crisis, the worst recession since the Great Depression, and very little progress beyond the IT industry. Given the circumstances, it's not surprising that our Y2K exuberance quickly fizzled. But it's not 2008 anymore. We made it through those challenges, and most of the technologies we expected are now arriving. We even reduced global poverty and child mortality along the way. Undoubtedly, the 2020s and beyond will come with new challenges. But we need innovation, diplomacy, and strength to solve these problems. And innovation, diplomacy, and strength are all downstream from motivation and optimism.

Maybe our excitement at the start of this millennium was not unfounded but simply premature. The evidence shows that we're finally starting to see the promises of the Y2K era. So, perhaps it's time to return to Y2K-style optimism, too, lest we blow this opportunity for advancement.

[^uc-artificial-kidneys]: Levi Gadye (2023): "Can an Artificial Kidney Finally Free Patients from Dialysis?" Published online by [University of California San Francisco](https://brandon.uno/links/639493611).
[^nature-xenohearts]: Nader Moazami (2023): "Pig-to-human heart xenotransplantation in two recently deceased human recipients." Published online by [Nature Medicine](https://brandon.uno/links/623798813).
[^bbc-lab-grown-blood]: James Gallagher (2023): "Lab-grown blood given to people in world-first clinical trial." Published online by [BBC](https://brandon.uno/links/469088742).
[^nature-cancer-vaccines]: Matthew J Lin (2022): "Cancer vaccines: the next immunotherapy frontier." Published online by [Nature Cancer](https://brandon.uno/links/477270477).
[^guardian-lung-cancer-pill]: Andrew Gregory (2023): "Lung cancer pill cuts risk of death by half, says ‘thrilling’ study." Published online by [The Guardian](https://brandon.uno/links/589311958).
[^um-sound-wave-cancer]: Jim Lynch (2023): "Tumor-destroying sound waves receive FDA approval for liver treatment in humans." Published online by [University of Michigan](https://brandon.uno/links/661230285/).
[^nature-anti-cancer-drug]: Jie Zhang (2022): "A microbial supply chain for production of the anti-cancer drug vinblastine." Published online by [Nature](https://brandon.uno/links/439607193).
[^uh-fentanyl-vaccine]: Laurie Fickman (2022): "Fentanyl Vaccine Potential ‘Game Changer’ for Opioid Epidemic." Published online by [University of Houston](https://brandon.uno/links/504078774).
[^tf-vaccine-meth]: Kamal Hossain (2020): "Vaccine development against methamphetamine drug addiction." Published online by [Taylor & Francis](https://brandon.uno/links/447544985).
[^pm-smartwatch-ptsd]: Nicholas D Davenport (2023): "A randomized sham-controlled clinical trial of a novel wearable intervention for trauma-related nightmares in military veterans." Published online by [PubMed](https://brandon.uno/links/470126597/).
[^ieee-smartwatch-diagnosis]: Michael Nolan (2023): "Parkinson’s Predicted From Smartwatch Data (seven years before clinical diagnosis)." Published online by [IEEE Spectrum](https://brandon.uno/links/606601138).
[^nature-ai-virus-prediction]: G. Wang (2023): "Deep-learning-enabled protein–protein interaction analysis for prediction of SARS-CoV-2 infectivity and variant evolution." Published online by [Nature Medicine](https://brandon.uno/links/619122572).
[^aging-yamanaka]: Jae-Hyun Yang (2023): "Chemically induced reprogramming to reverse cellular aging." Published online by [Aging](https://brandon.uno/links/606572994).
[^sa-ai-antibiotics]: Jaimie Seaton (2023): "AI Could Quickly Screen Thousands of Antibiotics to Tackle Superbugs." Published online by [Scientific American](https://brandon.uno/links/604696655).
[^bbc-antibiotic]: James Gallagher (2023): "New superbug-killing antibiotic discovered using AI." Published online by [BBC](https://brandon.uno/links/578783328).
[^lancet-antibiotic]: Douglas M. Heithoff (2023): "A broad-spectrum synthetic antibiotic that does not evoke bacterial resistance." Published online by [The Lancet](https://brandon.uno/links/521965522).
[^atlantic-ozenpic]: Sarah Zhang (2023): "Did Scientists Accidentally Invent an Anti-addiction Drug?" Published online by [The Atlantic](https://brandon.uno/links/576180254).
[^ieee-electronic-bandages]: Charles Q Choi (2023): "E-Bandages Lightly Zap—and Heal—Wounds." Published online by [IEEE Spectrum](https://brandon.uno/links/530787061).
[^bloomberg-clean-steel]: Akshat Rathi (2022): "Inside the startup cleaning up the steel industry." Published online by [Bloomberg](https://brandon.uno/links/455151488).
[^mit-aircon]: Amy Nordrum (2023): "Blue Frontier and its energy-efficient AC." Published online by [MIT Technology Review](https://brandon.uno/links/659371791).
[^mit-clean-concrete]: Casey Crownhart (2023): "Sublime Systems and its clean cement." Published online by [MIT Technology Review](https://brandon.uno/links/659371800).
[^mit-iron-batteries]: Casey Crownhart (2023): "Form Energy and its iron batteries." Published online by [MIT Technology Review](https://brandon.uno/links/659371809).
[^mit-geothermal]: James Temple (2023): "Fervo Energy and its geothermal power plants." Published online by [MIT Technology Review](https://brandon.uno/links/659371822).
[^sd-volcanic-energy]: Thomas F. Arciuolo (2022): "Yellowstone Caldera Volcanic Power Generation Facility: A new engineering approach for harvesting emission-free green volcanic energy on a national scale." Published online by [Science Direct](https://brandon.uno/links/517281883).
[^wid-solar-cost-decline]: Max Roser (2020): "Why did renewables become so cheap so fast?" Published online by [Our World in Data](https://brandon.uno/links/659371831).
[^neuro-desalination]: Steven Novella (2023): "Passive Solar Water Desalination." Published online by [Neurologicablog](https://brandon.uno/links/659371836).
[^time-greening-desert]: Charlie Campbell (2017): "China's Greening of the Vast Kubuqi Desert is a Model for Land Restoration Projects Everywhere." Published online by [Time](https://brandon.uno/links/659385884).
[^nyt-carbon-capture]: Peter Wilson (2021): "Is Carbon Capture Here?" Published online by [The New York Times](https://brandon.uno/links/659371864).
[^hit-co2-trees]: Cleo Abram (2023): "These Gene-Edited Trees Suck In More CO2." Published online by [Huge If True](https://brandon.uno/links/594859186).
[^brookings-euv]: Carrick Flynn (2020): "The chip-making machine at the center of Chinese dual-use concerns." Published online by [The Brookings Institution](https://brandon.uno/links/463113943).
[^arxiv-gpt-doctor]: Harsha Nori (2023): "Capabilities of GPT-4 on Medical Challenge Problems." Published online by [arXiv](https://brandon.uno/links/543762441).
[^gt-gpt-doctor]: Eric Topol (2023): "The GPT-x Revolution in Medicine." Published online by [Ground Truths](https://brandon.uno/links/545969773).
[^aviation-supersonic-jets]: Guy Norris (2023): "Boom Supersonic Begins Overture FAA Certification Process." Published online by [Aviation Week](https://brandon.uno/links/659371869).
[^nyt-talking-to-animals]: Emily Anthes (2022): "The Animal Translators." Published online by [The New York Times](https://brandon.uno/links/439052763).
[^wired-wireless-power]: Simon Hill (2023): "I’m Charging My Toothbrush With Wireless Power Over Distance—and It’s a Trip." Published online by [Wired](https://brandon.uno/links/661353656/).
[^nasa-asteroid]: Abbey A. Donaldson (2023): "NASA’s Psyche Spacecraft, Optical Comms Demo En Route to Asteroid." Published online by [NASA](https://brandon.uno/links/661465834/).
[^astroforge-mining]: Matt Gialich (2023): "Two steps closer to mining in deep space: Announcing two AstroForge missions for 2023." Published online by [AstroForge](https://brandon.uno/links/661718039/).
[^pew-technology-1999]: Pew Research Center (1999): "Technology Triumphs, Morality Falters." Published online by [Pew Research Center](https://brandon.uno/links/658279594/).
[^pew-optimism-1999]: Pew Research Center (1999): "Optimism Reigns, Technology Plays Key Role." Published online by [Pew Research Center](https://brandon.uno/links/658279603).
[^pew-dissatisfaction-2002]: Andrew Kohut & team (2002): "What the World Thinks in 2002." Published online by [Pew Research Center](https://brandon.uno/links/658279583).
[^pew-pessimism-2006]: Tom Rosentiel and Paul Taylor (2006): "America’s Optimists: More Republican, But Fewer of Them." Published online by [Pew Research Center](https://brandon.uno/links/658279549).
[^owid-optimism-and-pessimism-2018]: Max Roser and Hannah Ritchie (2018): "Optimism and Pessimism." Published online by [Our World in Data](https://brandon.uno/links/658279541).
[^pew-environment-pessimism-2019]: John Gramlich (2019): "Looking ahead to 2050, Americans are pessimistic about many aspects of life in US." Published online by [Pew Research Center](https://brandon.uno/links/658562305/).
[^gallup-optimism-2020]: RJ Reinhart (2020): "Record-High Optimism on Personal Finances in U.S." Published online by [Gallup](https://brandon.uno/links/658281188).
[^pew-non-parent-adults]: Anna Brown (2021): "Growing share of childless adults in US don’t expect to ever have children." Published online by [Pew Research Center](https://brandon.uno/links/658554686/).
[^pew-gov-trust-1999]: Pew Research Center (2023): "Public Trust in Government: 1958-2023." Published online by [Pew Research Center](https://brandon.uno/links/658279614).

Tags: advice, startups, society

# Your engineering org chart is your roadmap

As startups grow, leaders must decide how to structure their engineering teams. Intuition suggests that multiple small teams will be easier to manage than one massive team. So, any organisation successful enough to have more than a handful of engineers will eventually need to do some organisational design.

Knowing that you should divide your engineers into small teams is easier than knowing precisely how to do it. These days, cross-functional models for teams prevail, and most people know to avoid teams larger than five or so engineers[^1]. But how should product development efforts be divided across teams? 

My advice: your engineering organisational chart is your roadmap. While teams tend to frequently prioritise and deprioritise individual initiatives, what rarely changes is your team structure. Aligning your resources (in the form of engineering teams) to important focus areas is what it looks like to put your money where your mouth is regarding product development. 

Many startups talk about the important things, but when it comes to product development, they get distracted by shiny new product ideas, longtail features, and feature requests required to close new deals. But no amount of talk will deliver real results in product development. This hypocrisy is why startup leaders should permanently allocate engineering resources to the areas that matter most.

First, identify the core outcome that your product delivers to customers. While the value proposition for many products is a web of connected user benefits, most startups understand the core value they provide. Most SaaS products improve operational efficiency or increase revenue, for example. The better you understand the value you can deliver to customers, the more sensible your resourcing strategy will be.

Second, dedicate most of your engineering resources to your identified core value proposition. Because markets and technology constantly evolve, no product is ever complete. To protect and improve your position in the market, you must continuously improve your product and the technology that supports it.

Third, invest in the future. After achieving product-market fit, most companies underinvest in the customer onboarding experience. A dramatic reduction in the customer onboarding timeline for future customers is better than a feature that will help you win a few more customers because fast growth today is better than future growth potential. Eventually, the time comes when it is clear that you will exhaust your total addressable market. It probably makes sense to dedicate one or more teams towards market-expanding initiatives. Even now, you must continue investing in your core value proposition. It takes a surprisingly short window of neglect for a software product to become a painful liability, expensive to support, grow, and maintain.

![Most companies should invest most of their resources into advancing their core value proposition. For startups, this means always having at least one or more teams focused on this mission. Continued success in your core business is what enables you to invest in riskier, long-term bets.](https://static.fastertimes.cloud/post-attachments/resource-what-matters.svg)

[^1]: I've covered other principles of engineering organisational design, like cross functionality, [previously](/post/principles-for-structuring-a-product-development-team/).

Tags: advice, startups, operations

# How org design influences problem solving

Most startups let their organisational structure organically develop as they scale, but organisational design can surprisingly greatly impact outcomes.

Reporting lines have a big impact on how teams collaborate and what gets prioritised. It's natural for department leaders to prioritise their department's success (or perceived success) over company outcomes. Setting better company-wide goals can help with this, but organisational design is sometimes an even better solution.

When reporting directly to the CEO, with no other responsibilities outside of their department:

- An engineering manager will naturally focus on engineer outputs and avoid catastrophic incidents like platform outages. They might not care much about whether the features they build deliver real customer or business value.
- A product leader will naturally focus on product strategy and detailed scopes of work. If development is slow, they'll leave it to their peers in engineering to solve. If a customer is mad, they'll hope customer support can deal with it.
- A sales leader will do everything they can to achieve their sales goals. If the business struggles to onboard new customers, that isn't their problem.
- A support leader will focus on solving tickets. If crucial product feedback lives within these tickets, they might fail to gather and escalate this feedback in a usable way.

Independent leaders of teams tend to care mostly about the things under their control and by which the organisation will judge them. If a leader can succeed in their job by only managing towards the perceived success of their team rather than the business's overall success, they will often embrace this luxury. Why rock the boat with other teams unless it is necessary? This self-centricity is not their fault; focusing on what you can control is natural. Working in especially large or disempowered organisations trains people to work this way.

The problem with these departmental silos is that pain in one team is often a symptom of a problem in another team[^1]. Ineffective onboarding could be the fault of the customer success team. However, it could also result from poor sales qualification practices or product functionality gaps. When you solve a problem in the wrong team, you create a less effective and scalable organisation. For example, suppose you solve the onboarding problem in customer success. In that case, you might hire many unnecessary activation managers and support staff when it would be cheaper to improve the product. A product requiring a lot of hands-on help during the customer onboarding phase will struggle to scale compared to a simpler, self-service onboarding experience.

## Group teams with similar problems

One way to solve this challenge is to group teams that frequently clash. When leaders own multiple departments, they will consider how one of their teams can help another. The decision of where to solve a problem becomes explicit and intentional. If you want your product strategy to be fantastic and your engineering team to deliver quickly, a single manager accountable for both outcomes will do better. Suppose you want customers to go live within a week of sales closing. In that case, a leader who owns both sales and activation will consider both the activation process and how salespeople can set up new deals for success in onboarding.

## Keep executive teams small

To avoid fiefdoms from developing in the first place, startups should employ very small executive teams. Three c-suite executives with multiple department leaders reporting to them is enough to achieve diversity of opinion at the strategic level while ensuring your executives consider the total needs of the business at all times. 

## Embrace tension between teams when desirable

There are benefits to distance between teams in an organisational structure. Healthy tension can drive better outcomes for the business. If the success of one team is dependent on another, the first team is much more likely to hold the second accountable. Separate outbound and inbound sales teams, for example, can drive fantastic business results by demanding more from each other. The same dynamic can apply to other teams.

When deciding whether teams with shared challenges should work separately or together, consider whether your problem requires more collaboration or accountability. If you require more collaboration, it could make sense to merge your teams. If more accountability is required, segmenting teams into smaller units could work better.

[^1]: Many startup leaders address growing pains as they arise without thinking about what the root cause of any given problem can tell us about [where we should solve it](/post/fixing-startup-problems-in-the-right-place/).

Tags: advice, startups, operations

# Great startup leaders embrace conflict and discomfort

We are comfort-seeking creatures; focusing on longer-term goals and outcomes does not come naturally to us. As a result, organisations are biased towards creating comfort rather than business value. This bias is particularly evident in teams with elongated feedback loops, like product and engineering, because it is difficult to connect their effort with delivered value.

For example, the engineering manager focused on growth and therefore concerned with delivery pace, measuring real product outcomes, and making increasingly ambitious commitments is rare and of massive value. Instead, many engineering leaders optimise for technical excellence, professional development, and employee satisfaction. While each of these outcomes is important, engineering leaders must know when to sacrifice them for progress. This goes against human nature.

Most people want to create a harmonious work life so they avoid conflict. When faced with choosing between a painful but fruitful approach to a problem and a harmonious approach that will only deliver a mediocre outcome, many choose mediocre harmony. This concession might be OK for low-stakes decisions, but if you avoid conflict at the critical junctures in your startup's story, you'll only achieve disappointing results.

Conflict avoidance is one of the most dangerous traits in a leader, especially a CEO, given most organisations tend to be rife with the conflict avoidance of others. Great CEOs create clarity and accountability to goals. Great CEOs force the tough conversations and decisions that move the company forward (even when the answer goes against the CEOs' intuitions). Ineffective CEOs avoid conflict, allowing mediocrity to bloom. Ineffective CEOs add additional superfluous goals and distractions, prematurely diversifying the business. The same applies to any leader.

Should work not be comfortable? I think it should be fulfilling, enjoyable, and ergonomic[^1], but it shouldn't be easy. It should be awkward, painful, and messy. Because awkwardness, pain, and mess are where fulfilment and meaningful achievement emerge from. Comfort may seem nice, but it is the enemy of progress.

[^1]: How I distinguish ergonomics from comfort: Ergonomics is about reducing unnecessary hurdles to make it easier (and healthier) to do the right thing; Comfort is about reducing all hurdles (including necessary ones) to avoid pain in the moment, sometimes at the expense of long-term satisfaction.

Tags: advice, startups, operations

# How to choose KPIs for your startup

Ambitious projects need ambitious goals, and the best goals, whether KPIs, OKRs, or SLAs, track business outcomes rather than individual outputs.

|      Output/activity metrics      |  Outcome/results-based metrics   |
|-----------------------------------|----------------------------------|
| Call 100 prospects                | Close $20,000 in sales           |
| Ask 10 customers for a case study | Publish 20 case studies          |
| Ship 15 checkout improvements     | Increase conversion rate by 15%  |
| Build a partner program           | Close 10 deals with new partners |
| Launch inventory management       | 15 inventory management users    |

Without outcome-focused goals, teams get caught up with busy work. They work very hard but deliver little value. Churning out work becomes the definition of success, even if that work fails to deliver value to the business. Outcome-focused goals are ideal because they keep teams focused on delivering value; they are the definition of working smart, not hard. With outcome-focused goals, success is defined by impact, not effort.

Outcome-based goals have one major flaw: it can take time for effort to breed results. This delay is especially complicated when individuals or teams require others to take it to the finish line.

For example:

When a product development team delivers a new feature, they might have to wait for customer success to upsell it to customers, making it difficult to measure product development success based on user adoption.
An outbound salesperson can't be measured by closed sales (the ultimately desirable business outcome) when the sales cycle takes three months, and another salesperson owns it.

When setting quarterly targets, if it takes more than a quarter to impact the number you want to affect, aligning a target to that number doesn't make sense. If it's not possible to move the needle within a brief period, you have two options:

1. Tighten feedback loops. Sometimes, it's possible to remove the impediments that delay gratification. A more aggressive release schedule will help product teams to deliver results more quickly. Try to find and reduce these impediments.
2. Turn to output measures strongly correlated with the metrics you want to improve.

## Finding good output measures

Not all output measures are completely detached from the outcomes you want to achieve, but many are. When a team can't directly impact the numbers that matter most, the key to setting great targets is to identify activities that you know will eventually impact the numbers you care about.

It does not make sense to incentivise an outbound salesperson based on the number of emails they send because this output measure does not correlate with success. Sending 100,000 outbounds to poorly vetted prospects won't deliver value, but such a target incentivises them to do this. It also might not make sense to incentivise an outbound salesperson based on the number of closed sales. While this is the ideal desired outcome, if your outbound salesperson does not close deals because they hand them over to someone else (as is typically the case), they are relatively powerless regarding close rates. Long sales cycles might also delay the impact of their actions on this outcome-focused measure.

In a situation like this, finding another measure or activity that you know should correlate with success is usually best. This problem is why most salesforces will incentivise qualified leads — the number of high-quality potential deals an outbound salesperson generates. There is little correlation between outbound emails and closed-won deals. There is at least some correlation between qualified leads with interested prospects and closed-won deals.

Another example is case studies. Many teams wish to constantly expand their repertoire of case studies because this social proof helps them to sell. Teams often struggle here, though, because the creation of case studies usually requires at least two parties to be engaged:

- Customer support or customer success must identify good-quality candidates for case studies.
- Marketing must interview each customer, then write and publish the resultant case studies.

In this situation, giving customer success a KPI for the number of case studies you create is probably a mistake because they're powerless when it comes to half of the process of creating case studies. In this situation, you have two options:

1. Remove impediments to tighten feedback loops. The most obvious way is to have your customer success team write and publish the case studies themselves, which may or may not be a good idea for your business.
2. Choose an output measure strongly correlated with case study creation that your customer success team can own. The obvious option here is to track and measure the number of case study opportunities they submit to your marketing team. You can then separately incentivise your marketing team on the percentage of these opportunities they manage to get live within a certain timeframe.

## All output measures are flawed

Whenever you create distance between the business outcomes that matter and the goals and targets for your teams, you increase the likelihood of unproductive, busy work taking over. Business success is about pragmatism, though; an imperfect measure is better than no measure.

This reality is why it's important to never take your eyes off the outcomes that matter. The KPIs for your teams must compound into these outcomes. For sales teams, incentivise top-of-funnel salespeople on qualified leads and bottom-of-funnel salespeople on conversion rates (in the form of revenue targets calculated by multiplying the expected number of qualified leads by your desired conversion rate). In this environment, if both teams achieve their KPIs, they'll achieve your desired revenue goals. Splitting the funnel into separate KPIs makes it obvious where to focus when things go bad.

Another way to improve output-based measures is to try to measure quality. On a slow month, an outbound salesperson can lie to prospects about the capability of your product to meet their target for opportunities. This conflict is why most outbound sales teams have more than just this KPI. It's common to quantify quality with criteria for lead qualification, which could consider the size and industry of the customer and their need for key features.

Tags: advice, startups, sales

# Why development teams slow down

As startups scale, software development speed tends to slow. If you can't ship product improvements quickly, you can't quickly solve problems for your business, and you have a higher chance of failure[^1].

This sentiment is one of the most common conversations I have with founders: "We used to move so quickly, but now we've barely delivered anything all year." Let's look at some of the most common causes of reduced software delivery.

- Engineers understand customer needs and existing product functionality less. Scoping takes longer, and we release many features that need significant rework to meet customer needs. This decline in customer empathy is usually the result of reduced exposure to customers, with middlepeople like designers and product managers monopolising customer contact.
- Engineers tackle too many initiatives simultaneously[^2], making extremely gradual progress on many things and rarely completing anything. This problem is usually the result of poor prioritisation. More focus is always better.
- The team has committed to far too many customer deliverables[^3], leaving them no room to set their strategy, pivot based on their learnings, or address the needs of the broader customer base. These teams should only sell existing functionality, never making promises about future functionality to prospects. Teams should also avoid product commitments to existing customers.
- The product has become too broad[^4], with too many features to maintain and improve, making it impossible to meaningfully improve the product for most customers within a short period. This problem results from teams expanding their product more aggressively than they expand their engineering team. These teams should ruthlessly deprecate features or grow their team (if they can afford it).
- Leadership constantly sends teams down rabbit holes, chasing shiny new ideas and rarely finishing anything, rather than following customer and market needs[^5].
- Releases are manual or infrequent, or customer upgrades are opt-in. This infrequency elongates feedback loops, making it impossible to quickly iterate on features, forcing teams to build and deploy big-batch changes loaded with untested product decisions and risky technical changes. These teams should prioritise DevOps[^6], particularly continuous deployment.
- The team has failed to create reusable patterns (like a design style guide[^7], utility functions, standardised methods/APIs), so they must start from scratch every time they build something new.
- The team is inundated with bugs and incidents and lacks new feature development capacity. These teams should shift to maintenance-first development, focusing on rebuilding chunks of the product individually, eliminating bugs in bulk and improving functionality as they go. A zero-bug policy for rebuilding parts of the system will help to avoid falling into this situation again.
- When the CEO made most product strategy decisions, they made these decisions quickly and decisively. Now that product managers and designers make these decisions, they are overly careful and hedge their bets, fearing being blamed for a misstep. More iterative development and scoping deadlines can help with this issue.
- Product managers, designers, and engineers spend excessive time communicating and managing the perception of their delivery when they could spend much more time on delivery. This distraction is usually because leadership, boards, investors, customers, or peer teams require them to create roadmaps, progress updates, marketing content, and company-wide presentations as a reflexive solution to slow development when they should spend more time on delivery.
- Product managers, designers, and engineers don't spend enough time communicating what they deliver, so they are perceived to be less productive than they are.
- Engineers over-index on career advancement or intellectual stimulation when making technology and architectural decisions. When a simple and more pragmatic alternative is available, they needlessly migrate to a hot new framework, architecture (microservices), or language. This distraction adds unnecessary complexity to the development process.
- Product managers, designers, and engineers work hard to look good rather than do good. When individuals act out of self-interest, towards promotions or status, rather than real business outcomes, management must realign incentives towards business outcomes. When a business incentivises real outcomes, even the most self-serving individuals can deliver great results.
- Product managers, designers, and engineers spend excessive time in meetings, discussing problems rather than solving them.
- Decision-making requires too many approvals, and approvers are unresponsive. These organisations should empower teams to make decisions, noting that effective empowerment balances autonomy and accountability[^8]. Make it clear what type of decisions teams can make and what type of decisions sit with management.
- To manage costs, leadership has hired more affordable and, therefore, less experienced or effective engineers, watering down the output capacity of the team.

There are also some good reasons to slow down software development speed.

- The team is now more focused on outcomes than outputs[^9], so while they ship fewer features, the features they do ship attract much more usage and, therefore, better business outcomes.
- Quality gradually becomes more important as the customer base grows. The team used to deploy untested code, refactor features overnight, and deploy half-finished features to individual customers. Now, the cost of a major bug in production is severe. Similarly, the cost of poor product decisions is greater[^10]. So, teams must be more careful and thorough, writing automated tests and testing features more completely before release.
- The product has a more diverse customer base, making it more arduous to survey customer needs[^11] and more complex to build a feature usable by a large chunk of the customer base.
- By under-investing in maintenance, the team has let technical debt accumulate and has a legitimate need to pay this debt down. These teams should shift to maintenance-first development to deliver product improvements while paying down technical debt.
- The business previously took far too many legal/regulatory and cybersecurity[^12] risks and now must consider these risks as teams scope and build new features.
- The team previously worked with unreasonable intensity for unreasonable durations, leading management to expect burnout-inducing speed.

[^1]: [Rapid product development drives outcomes in startups](/post/developer-velocity-drives-business-growth).
[^2]: The negative impact of cognitive overload on productivity is well-established in research, [but startup leaders rarely factor this into their strategy and operations](/post/manage-cognitive-load-to-build-a-productive-startup).
[^3]: Promising future features to new and existing users almost always leads to poor outcomes and a lack of control over your product strategy, [because they build up over time and eliminate opportunities to adjust course](/post/resist-the-urge-to-sell-features-from-the-future-to-your-customers).
[^4]: The ideal state for product-market fit is to have [an extremely narrow and focused product that satisfies a very broad market](/post/focused-solutions-for-large-markets).
[^5]: You need organisational discipline to focus on the right things and not be distracted by the wrong opportunities. [You also must be capable of determining how common and complex the problems you are prioritising are](/post/build-for-your-market-not-the-next-deal).
[^6]: DevOps is more than product management, and [you should invest in it first when facing scaling issues](/post/devops-or-product-management).
[^7]: Investing in product design can lead to fantastic outcomes for product development teams of all sizes because it [reduces the number of iterations required to produce a great product or feature](/post/embrace-design-ops).
[^8]: Autonomy and accountability are intrinsically tied together. To achieve great results, people need control over what they do (autonomy) and they need to be motivated by real business outcomes (accountability). [Effective delegation requires a balance of these two forces](/post/how-accountability-enables-autonomy).
[^9]: [When starting an initiative, it’s important to focus on the desired outcome before jumping to solutions](/post/focus-on-outcomes-over-outputs). By focusing on the problem to be solved, we can ensure all ideas are considered and that we are all working towards a common goal.
[^10]: Teams can [stay ambitious with the help of experimentation](/post/stay-ambitious-with-the-help-of-experimentation).
[^11]: To make effective decisions when developing products, engagement with customers is critical. [Building this into your way of working should be the priority of any product leadership](/post/customer-feedback-strategy).
[^12]: Many startups never outgrow their poor security habits. [For every high-profile breach, many early-stage startups face existential risk due to poor security posture](/post/cybersecurity-for-startups).

Tags: advice, startups, operations

# Build credibility with case studies and testimonials

All products require some effort or cost to adopt. It's much easier to convince your customers to take a risk on your product if you have proof that it has delivered great results to other businesses, especially if these businesses are well-known, similar to, bigger than, or respected by your prospects. Evidence of delivered value turns a lack of reputation into a great reputation and growth inertia into sales momentum. In the form of testimonials, metrics, and case studies, social proof is one of the most important assets for early-stage startups to build.

Start simple and highlight the successful and trustworthy parties you're associated with. The best association to highlight on your website, pitch decks, and sales collateral is your customers. Display some customer logos in all these materials, and ensure your terms and conditions allow you to do this. If you're short on impressive customer logos, consider other associations that could boost your credibility. These logos might include investors, partners, mentions in the media, and alumni logos (corporate or educational).

![Tana.inc lists the employers of its customers on its website. The Goldfinch.finance website lists its investors. Socket.dev lists its customers. Sauce.app lists the former employers of its founders.](https://static.fastertimes.cloud/post-attachments/socialproof-options.png?a)

Testimonials are even better than logos and are easy to solicit and publish, making them another good place to start. Ask key customers, partners, or investors to write a short endorsement for your product or team. Feature these testimonials prominently in your sales and marketing collateral, particularly your website. Tailor testimonials to each context. Employee or investor testimonials work great on careers pages, partner testimonials for partnership collateral, and customer testimonials by far most effective for content targeted at prospective customers.

![AudiencePlus.com features customer testimonials on its homepage.](https://static.fastertimes.cloud/post-attachments/socialproof-audienceplus.png?a)

Case studies tend to boost your credibility even further, though they are more effort to produce. Work with your greatest success stories to turn them into detailed case studies. The more outcome-focused a case study is, the more effective it will be. So, talk about the results your product and team have delivered to your customers. While potentially expensive to produce, video case studies can serve as foundational content for social media content and advertising.

Data is the best way to credibly communicate the value delivered. Many startups leave it far too late to measure the impact of their products. If your product drives revenue or saves costs, quantify this impact and communicate it as much as possible. Consider this on a per-customer and platform-wide basis, and include these metrics in case studies and other relevant content.

![Reveal.co highlights measurable customer outcomes on its website.](https://static.fastertimes.cloud/post-attachments/socialproof-metrics.png?a)

Turn every success story into a case study. This goal should be one of the primary responsibilities of any B2B marketing team, and every team should support this effort:

- Customer success must frequently request testimonials and case studies from customers. Set KPIs for customer success that drive them to generate case studies and testimonial opportunities.
- Survey customers to identify happy customers who should be case study candidates.
- Use data to identify success stories within our customer base. Notice when your product 
- Respond to positive feedback (*e.g.,* CSAT, NPS) requesting a testimonial or case study.
- Work within your means. Creating several case study articles yearly is much better than just one or two videos. Graduate from logos to testimonials quickly, testimonials to case studies when you recruit your first marketing hires, and only add videos once it's easy to consistently produce the rest without disruption.
- Cover all of your key customer segments. If you sell to small businesses and enterprises, ensure you have case studies for both. If you sell to multiple industries, have a case study for each industry. Prospects will trust testimonials that align with their own business.

When starting from scratch, some startups succeed by targeting notable businesses as their first customers. Winning a few notable logos early in your product's lifecycle can boost your credibility with other early prospects.

Tags: advice, startups, sales

# Is your startup a good idea?

Startups are ideas in action. However, not all ideas are created equal. Let's explore how startup leaders can use the concepts of feasibility, desirability, and viability to quickly and reliably validate startup, product, and feature ideas.

## Is your product feasible?

Some products are easy to build; others are impossible. The more confidence you, your customers, and your potential investors have in building your product, the greater the feasibility.

A startup that depends on novel technology nobody else has deployed has a high risk of being unfeasible. A startup that only depends on mature technologies is much easier to build. Some problems require novel solutions; others are easy to solve with existing techniques.

- A startup that aims to instantly perform hundreds of blood tests with a single drop of blood has a massive degree of feasibility risk. Nobody in history has built a solution like that, so it's a leap for investors, partners, customers, and employees to jump on board.
- A startup that aims to build a SaaS solution for online retailers will most likely recycle mature technology already validated by a massive industry of B2B SaaS companies. Investors, partners, customers, and employees will find it easy to endorse a solution like this.

If your solution requires novel technology, your priority as a founder should be to validate your technical approach. Build a prototype or proof-of-concept to prove that your solution is feasible. Without this well-founded confidence, you will struggle to raise capital, recruit a team, and convert customers.

Sometimes, a lone technical founder can build this proof of concept before raising capital, hiring a team, or finding early adopters. Sometimes, you require a team of deeply technical people for research and development. It can be difficult to raise capital just to validate a technology, especially if it will be expensive to do so. Investors will consider things like your experience as a founder, your credibility as a trailblazer in your technical field[^1], and your product's potential value if you succeed[^2].

If you fail to prove feasibility, you should find a new solution or perhaps an entirely different problem to solve. Ideally, you'll come across alternative ideas to try in your efforts to validate your original ideas.

## Do people want your product?

Some products are easy to sell; others are impossible (because nobody wants them). A desirable product is one that the market yearns for.

Some startups solve such big problems that it's obvious they will be desirable. One of the solutions previously mentioned fits this description: everyone knows that blood tests are a common occurrence, so a major patentable improvement to the customer experience will inevitably present a big opportunity. In contrast, yet another B2B SaaS solution may require more proof of desirability.

Desirable B2B products always:

- Increase or protect revenue for their customers. Shopify, for example, makes it easy for retail businesses to collect revenue online.
- Reduce operating costs for their customers. Zendesk, for example, helps customer service teams to work efficiently, reducing the costs of operating a support team.

If you can accurately quantify a productive impact on your potential customers' revenue or operating costs, you can safely assume your product will be desirable. The best way to do this is to recruit some early adopters and build the product with them. Measure the impact of your product, and use this measure to guide your product strategy and your pitch to new customers, staff, and investors.

Another way to validate desirability is to start selling. Many startups launch with a simple website to collect expressions of interest long before they build their solution. These days, it's easy and affordable to conduct some top-of-funnel marketing efforts like digital advertising, content marketing, and outbound sales before you have a product. The potential customers you collect will help you to prove that your product is desirable, and many of them will be suitable early adopters for your product as you build it.

If you fail to prove desirability, you should find a new problem to solve. Ideally, you'll come across alternative ideas to try in your efforts to validate your original ideas.

## Is your startup viable?

A harsh truth of startup building is that startups with good solutions to valuable problems can still fail; this usually happens because they fail to build a viable business.

It's not enough to solve an interesting problem. You also need to:

- Ensure your problem is big enough to justify pricing that can support your operations and price your product accordingly.
- Build a scalable, repeatable, and profitable sales model where you can recruit new customers who pay you more than you paid to acquire them.
- Build a product onboarding experience that enables you to grow quickly without an excessively large professional services team.
- Build a mostly self-service user experience that allows you to keep a lean and affordable customer support team.
- Build a reliable and easy to maintain technology stack that doesn’t slow down product development or cause problems for customers.
- Continue to deliver new value to earn more from each existing customer and retain them long-term.
- Maintain the flexibility to pivot around unforeseen market, competitive, or regulatory challenges.

The good news is that very early-stage startups have time to prove viability. If you have a desirable and technically feasible product, you should be able to raise enough capital to work your way towards viability as you scale.

Early-stage startups should strive to prove both desirability and feasibility immediately upon founding, understanding that the bar for proving each varies depending on your chosen problem and solution. Once you're confident in these areas, your job is to build a viable business.

[^1]: It’s easier to raise money for a rocketry startup if you have a PHD in Hypersonics and Rocketry and have worked at SpaceX.
[^2]: Wise investors won’t take big risks on startups with limited upside. The greater the potential return, the easier it is to justify a risky and unproven approach.

Tags: advice, startups, strategy

# Tackling customer churn

Startups often neglect customer retention until churn becomes a severe problem. Successful early-stage startups tend to grow quickly, and growth hides churn. But churn is usually a big problem for startups before they notice it. Churn can seriously hamper growth at all startup stages, and when a startup grows without managing customer retention, it turns into a leaky bucket. Eventually, no matter how much you sell, churn will drag you down. 

## It takes time to profit from new customers

It's expensive for B2B SaaS companies to acquire new customers. Many scaling companies spend more to acquire each new customer than their average customer pays them in a year. This upfront sales and marketing cost means it can take over a year to earn back the money you spent acquiring each new customer.

The longer your CAC Payback Period (i.e., the number of months it takes for a customer to pay you as much as you paid to acquire them), the more risk there is that some customers will churn before they've paid you back. A company struggling to profit from new sales does not yet have a scalable sales model.

Startups should:

- Measure their CAC Payback Period and aim to keep this under twelve months.
  - Startups with a high CAC Payback Period might need to rightsize their sales efforts or increase their prices.
  - Startups with a low CAC Payback Period might be well-positioned to ramp up their sales and marketing efforts.
- Measure their average time-to-value (the time it takes for the customer to receive their promised value from the product, i.e., onboarding time).
  - It's always better to deliver value sooner.
  - Customers yet to receive value from a product are most likely to churn.
    - Every time a customer receives an invoice for a product they don't use, the risk of churn increases. Measure and reduce the number of invoices customers receive during their onboarding period.
  - Startups with a high CAC Payback Period should strive to deliver value very quickly to maximise the chances of customer retention throughout the payback period.
- Focus on improvements to the early stages of the customer journey. It takes a lot of work to win back a burned customer. Conversely, customers who trust you have more tolerance for future issues.

## Keepers are cheaper

Retaining a customer is usually much cheaper than finding a new one. Most scaling SaaS companies spend thousands of dollars to acquire each new customer. Every time a customer unexpectedly churns, your sales target increases to make up for it.

Startups that invest in customer retention achieve scale sooner because, when looked after, SaaS customers are very sticky.

Startups should:

- Check in with customers to understand overall customer satisfaction. You can do this through surveys and 1:1 interactions/meetings. Capture these insights as measurable data.
- Quantify and improve the value each customer receives from the product. Less active customers are more likely to churn.
- Urgently respond to negative feedback and interactions. Follow up immediately when a customer submits a negative NPS/CSAT survey or complains to your team.
- Switch to a proactive customer service model. Most teams simply react to requests and complaints from customers. Excellent customer service teams look for leading indicators that predict dissatisfaction before it happens.
  - Identify and manage slightly delayed customer onboarding projects before they spiral out of control.
  - Automatically trigger support cases based on software logs and errors.
- Respond to reduced product usage indicators.
- Improve customer utilisation over time. Many customers use only some features of the products they license. Selling new and existing features to existing customers makes you more money and helps them get the most value out of your product, improving customer retention. This advice especially applies to features the customer pays for but has not used.

Startups should also quantify the total cost of customer churn, including the knock-on sales costs incurred every time a customer churns. When a customer churns, they cost you:

- The money you spent to acquire them, if they haven't paid it back.
- Future revenue you could've earned from them.
- The money you must spend to gain another customer in their place.

## Churn is a big problem at scale

Startups need to compensate for a shrinking customer base through new sales. This leaky bucket can seem manageable for early-stage startups, but it becomes costly and difficult to solve at scale.

When you have 100 customers, a 3% monthly churn rate costs you three customers per month. So, to hit your sales targets, you must sell to three additional customers per month. Early-stage startups often enjoy high growth rates, so a few extra sales are trivial to make.

When you have a thousand customers, a 3% monthly churn rate costs you thirty customers per month. You must sell to thirty additional customers per month to hit your sales targets. This bleeding could consume multiple salespeople's efforts for the entire month. 

At scale, startups tend to grow more slowly, exacerbating the impact of the same churn rate as a smaller startup. Your churn rate directly reduces your growth rate. Shaving 5% churn off a 200% growth rate isn't a big deal. Taking 5% churn from 15% is enormous — a third of your total growth flushed away.

Startups should build good customer retention habits early. It's easier to scale these efforts as you grow than to start from scratch as a mature scale-up. If you tackle churn when your growth rate is high, growth will compound better over time. Most importantly, if your growth starts to slow, your business won't be at risk.

Tags: advice, startups, operations

# Product documentation 101 for startups

Most startups under-invest in their product documentation — when you're busy with reactive customer support, it's hard to justify proactive work like documentation. However, quality user documentation can dramatically reduce support team workloads and free up product development and customer acquisition resources.

## Integrate documentation into your ticket lifecycle

The easiest way to build a helpful knowledge base is to enact a policy where you and your team always respond to customer support queries with a link to a document. When a customer asks a question, check if a document with an answer to that question exists. If one does, respond with a link to that document. If one exists, but it doesn't quite answer their question, improve the doc and respond with a link. If a document doesn't exist at all, take the time to write one up.

It takes a little more time to write a help document than to reply to a support ticket, but a little effort now will save you a ton of effort later.

Apply this same policy to escalated cases. When the support team cannot answer a question in most startups, they escalate to the product development team. Your engineers should respond with updated documentation.

A genuine commitment to improving documentation with each new support case will gradually transform your company. It'll be easier to respond to tickets because answers will be readily available to your team. Customers will submit fewer requests because they'll eventually learn to check the docs first. Training new employees will be easier.

## Document new features before you launch them

Major feature releases can cause pain for customer support teams because they dramatically increase the surface area of the product for which there is no documentation.

The easiest time to document a feature is towards the end of the development process. It's easy to forget the details of expected functionality over time. But, if you write documentation like automated tests — integrated into the development process[^1] — you'll produce accurate documentation for your team with little extra effort.

Documentation written by your engineers might require some finessing by your support team. Your team can improve documentation iteratively, though. It's better to start with comprehensive and accurate docs than nothing.

## Capture feedback and analytics

Great documentation is the outcome of sustained effort, and feedback is fuel for small improvements. Make it easy for customers, staff, and partners to submit feedback for any document in your knowledge base. This feedback should go into a backlog for your support or product team to promptly action.

Web analytics can be another valuable feedback mechanism. If you observe the traffic on your knowledge base, you can understand the areas of the product that people need help with or have an interest in[^2].

## Publish everything

Many teams maintain separate public documentation for their customers and private internal documentation for their staff. While there are occassionally good reasons to do this, this is usually a mistake. Teams with internal product documentation tend to publish many new documents internally first with the intention to later polish them and publish them for customers. The problem is, most teams never get around to this. Teams end up with great internal documentation repositories, and underwhelming documentation in production.

To solve this problem, ban internal documentation in most situations. Publish all documentation for customer use by default. It usually only takes a little more effort to polish an internal document for general availability. If you invest this effort in real time, your documentation will be a lot better.

## Deflect cases

Training customers to check your documentation before reflexively contacting you about a problem can be difficult. If you require customers to contact you via a web form rather than email[^3], you can present them with useful user documentation before they submit their query. This tactic is called case deflection, and all good knowledge-base software supports it[^4].

If you don't have any case deflection capabilities or even a knowledge base, collecting customer support enquiries via a form on your website is still a good idea. It can be excruciatingly difficult to transition customers accustomed to emailing you to a web form. If you start early, you'll save yourself from pain in the future.

## Pay attention to support metrics

Every support ticket you receive is a failure of documentation. When customers submit a case, they implicitly tell you that your documentation is insufficient or difficult to navigate or search.

Every support ticket you receive is also a failure of product capability and user experience. Great product experiences require less documentation (and manual support) than poor product experiences. Documentation is a hedge against product complexity, so the same insights that improve documentation should also improve your product if you pay attention to them.

[^1]: It's possible to automatically generate documentation for APIs, making it easy to keep documentation specific and up-to-date. API documents are the most difficult documents for your support team to maintain and improve. Automating this process can empower your support team to focus on end-user documentation.
[^2]: Good help docs can be fantastic for SEO and organic web traffic. Users searching for general advice often land on help docs for products they don't use. Do what you can to convert these guests into customers.
[^3]: Most live chat tools support case deflection, too.
[^4]: Generative AI will massively improve case deflection; green shoots are already sprouting up in this space. Good documentation will enable generative AI tools to provide automated customer service.

Tags: advice, startups, operations

# Always look for the problem

When someone requests a product feature, a change to your ways of working, or raises any sort of idea, they typically come to you with a suggested solution.

- We should implement a live chat feature on our website to improve customer support.
- We need to develop a mobile application to increase our user base.
- We should integrate with Google Calendar to remind users about their scheduled tasks.
- Let's create a referral program to attract new customers.
- We need to add push notifications to keep our users engaged.
- We should incorporate blockchain technology to ensure secure transactions.
- We need to build a comprehensive FAQ section to reduce the number of support queries.
- We should offer 24/7 customer service to better assist our international customers.
- Let's invest in a new CRM to streamline our sales process.
- We should adopt product analytics to better understand our customer behaviour.

These requests are all proposed solutions. For some, it is obvious what problem they solve. For others, it requires some digging.

While these ideas all sound convincing, even the best sounding solutions can be flawed for two reasons:

- When you jump to a solution without exploring the underlying problem, you never get the chance to scrutinise the characteristics, importance, urgency, or ubiquity of the problem. Interest or excitement does not translate to importance. Sometimes, the most exciting ideas are superficial and solve unimportant problems.
- When you accept a suggested solution, you fail to consider other potential solutions[^1]. There is usually a simpler, easier-to-implement, and more effective option than the first solution that comes to mind.

Startups are idea-rich and resource-poor. So, spending your limited resources on the most important problems is important. Startups that chase exciting ideas and fail to scrutinise problems fail to deliver great customer outcomes and become mediocre over time.

## Finding operational problems

While it's common for product managers and engineers to look for underlying problems when they receive a feature request, teams rarely apply the same scrutiny to internal operational suggestions.

Ideas for new or adjusted ways of working are as common as feature requests:

- We need a weekly meeting between marketing and product to ensure we're on the same page with new feature releases.
- We need to hire a product marketing manager to coordinate product messaging.
- If professional services and products met on a regular cadence, we could
- If product managers join kick-off calls with new customers, we can identify
- If professional services join sales demos, we can ensure the people responsible for project delivery have a hand in project scopes.

These ideas sound reasonable, so most organisations embrace such suggestions without scrutiny. But it's problematic to jump to a solution, whether it's a product idea or an operational change. As expensive as product development is, bad operations can cost even more over time.

More broadly, the inconvenient truth of startup and business operations is that there are no fundamental truths applicable to all businesses. Different business models and organisational structures may be biased towards certain operating principles. But, there are so many operating variables that every business should work differently. Ideas about operations, usually informed by experience in other businesses, can be as ill-fitting as even the worst product ideas.

So, startup leaders should examine every new and existing process for inefficiencies. More importantly, leaders should scrutinise new ideas.

- Various problems could lead a marketing team to request a weekly meeting with the product. Perhaps they're frequently blindsided by new releases and don't have time to prepare communications. Or there could be a lack of alignment between what marketing and product understand to be the ideal customer profile or value proposition. A startup can solve these problems in various ways besides an expensive meeting with an ambiguous agenda.
- Dissatisfaction with development velocity or product strategy undergirds most requests for a detailed product roadmap[^2]. Teams should instead address velocity and strategy problems or disagreements head-on. Velocity is a particularly insidious problem because most suggestions (typically more artefacts like roadmaps or more meetings) slow teams down.
- Professional services and customer success teams suffer when a sales team sells professional services that are particularly tricky or impossible to deliver. Professional services teams might demand involvement in the sales process as a solution. But, this would slow down the sales process. A startup that values sales velocity might consider other options, like standardising professional services to a point where it's much easier to sell them.

Every startup problem has multiple solutions, and teams that operate effectively tend to deliver better results. So, it pays to spend a little time on each problem before you add a new meeting or process.

## Finding customer problems

Understanding customer problems is a fundamental part of any startup's operation, and this extends to product teams. They receive numerous feature requests from customers, yet the challenge lies not in implementing them all but in understanding the core problem these requests are attempting to solve. More often than not, these feature requests are solution-driven, highlighting the proposed solutions rather than the underlying problems.

When dealing with these solution-based requests, product teams must apply the principles of problem exploration. Instead of jumping straight into the suggested solution, teams should dig deeper to comprehend the root cause or problem that led to the feature request.

Let's say customers are asking for an in-app tutorial or product tour. It might seem that the solution is to create a comprehensive walkthrough. But upon closer examination, the product team may find that the real issue isn't a lack of a tutorial but rather that the app's interface is not intuitive enough. In this case, a more effective solution might be redesigning some UI elements for a better user experience instead of investing resources in creating an in-app tutorial.

Suppose customers are requesting a feature to download and save content offline. At first glance, the solution is to add an offline mode. However, if the team investigates the underlying issue, they might discover that the problem is intermittent or slow internet connections impacting user experience. In this case, optimising the app for lower bandwidth conditions might be a more viable solution rather than creating an entirely new offline feature.

Another example could be customers requesting an in-app messaging feature. Instead of building an entire messaging system, the team should identify the problem. Is it because users want a faster way to connect with support, or do they want to communicate with other users? In both cases, implementing an entire messaging system could be an overkill when simpler, more effective solutions are available.

Unearthing the true problem helps startups better allocate their resources, focusing on the most urgent and important needs rather than getting carried away by exciting solutions. This ensures a more effective problem-solving process and drives customer satisfaction by delivering more targeted and useful solutions.

A startup capable of listening to its customers and, instead of taking its proposed solutions at face value, delves deeper to understand the real issues is one that stands a better chance of delivering a product that meets customer needs in a meaningful way. As such, always remember to place the problem first and the solution second. In doing so, your startup will make the most of its resources, cater effectively to its customers, and ultimately thrive in a competitive market.

[^1]: Ideas that come in the form of solutions are problematic because they are the product of [premature convergence](/post/find-the-best-opportunities-and-solutions-with-divergent-ideation/).
[^2]: Roadmaps can be a form of [commitment debt](/post/resist-the-urge-to-sell-features-from-the-future-to-your-customers/).

Tags: advice, startups, operations

# Great startups challenge industry norms

After news that Airbnb, Figma, and a few other high-profile tech companies have abolished the product manager role within their organisations, the startup world is awash with stories and takes on whether product managers are still necessary. This topic is an excellent opportunity to explore why startups must challenge industry dogma and take risky bets, even regarding "solved problems" like organisational design.

Every product development team needs to find valuable problems to solve, discover suitable solutions to those problems, and build and deliver these solutions. Whether a small group of developers do this without help depends on the nature of their industry/problem space and the experience/competence of the team.

Suppose you want to build a SaaS solution to solve a problem for software developers. It will be easy for you to recruit developers who understand the problem, can find a solution, and can implement it.

Similarly, some products (like Figma) target product designers. It's a no-brainer that product designers should lead these teams — the ultimate subject-matter experts for their market.

The same could be true for a startup that targets the general public. Airbnb solves an almost universal problem: most people like (or occasionally need) to travel, and anyone who travels needs accommodation. So, it's pretty easy for Airbnb to find developers who understand the point-of-view of their customers and can therefore build solutions without help from product managers.

Most B2B SaaS companies, on the other hand, solve niche problems. It's challenging to recruit software engineers who understand the needs of radiologists, urban planners, or machinists. To target these users, teams need to understand their needs. One of many ways to do this is to recruit a product manager with industry experience or at least one with a great understanding of the principles and frameworks that a team can employ to understand their customers more intimately.

Every company exists somewhere on this spectrum. Some don't require product managers because it's easy for a large workforce of engineers to own product strategy. Some teams can learn about their users' needs but require some guidance. Others operate in complex or niche enough industries that may need a subject matter expert or facilitator on the team.

Leaders hire people to solve business problems. So, what business problems do startups typically hire product managers to solve?

Some possible answers:

- We want our teams to make better decisions.
- Our teams need to be more organised and work more effectively.
- We need more coordination across multiple development teams.
- We need better coordination with other departments.
- Our team needs leadership.
- Everyone else hires product people, so we should too.

Notably, you can solve these problems without hiring a product manager. That's not to say that hiring a product manager is a bad idea, only that it's one of many pathways.

If you want your teams to make better decisions, you could hire developers with more relevant experience or a proven ability to work directly with customers to understand their needs and find solutions. You could increase the amount of exposure your team gets to customers. You could weaponise your customer success team to convert anecdotal product feedback into actionable data. Or, you could hire a product manager[^1].

If you want to improve the success of product launches, you could incentivise your team to deliver measurable outcomes rather than churn through tickets. You could encourage direct collaboration between engineers and product marketing. You could rethink your strategy to ensure your expectations are realistic. Or, you could hire a product manager.

There are many ways to build a great product. But, to win big, you need some contrarian tactics. You can't make a differentiated business if you don't do things differently. As a startup leader, you have two choices when you see the entire industry settle on a standardised way.

First, you can adopt the standard. Do what everyone else does. This approach is excellent because it allows you to solve the problem and move on. You don't need to waste time reinventing the wheel. You can focus on the decisions that matter most.

Your second option is to buck the trend. Do things differently. Find a better way or at least one that works better for you. In the world of business and the business of technology, there are no timeless truths. Every rule expires as new technologies and ideas emerge. Moore's law is over. Product management, as we know it today, may have peaked. But, as far as I can tell, there will always be problems and solutions to innovate around. Your job is to find the best way for your chosen problems. Your job is to find your edge. It could be hiding *anywhere*.

[^1]: Many organisations delegate strategy to product managers. This can deprive engineers and designers of the opportunity to fully engage in the strategic process and exercise their decision-making muscles. Why does this matter? If an individual product manager can easily call the shots, it doesn't matter. Many companies are driven by a handful of astute, effective, and wise product managers. Many engineers and designers are happy to be led by product and focus on expert execution rather than strategy and tactics. But, if you need teams to make complex decisions that require deep and diverse expertise, you need the people with this expertise to be competent strategists. A product manager can get in the way of this.

Tags: advice, startups, operations

# Why startups should act their age

When an early-stage startup acts like a mature software corporation, progress grinds to a halt. Because the journey towards product-market fit requires high-velocity experimentation, an early-stage startup hindered by a mature business's ways of working could fail before it gets off the ground. Speed is more important than quality.

Conversely, when a mature product organisation behaves like a startup, with a lackadaisical attitude towards quality and inefficient business operations, it is consumed by technical issues, bugs, tech debt, and HR problems. Quality becomes very important at the expense of speed.

This principle is one of the reasons why it's so challenging to build a successful startup: what works for you in the early days can be your downfall after you've achieved some scale. Similarly, what worked for you at your previous job (at a mature software company) will encumber your new venture. As a result, many startups get stuck in quicksand between product-market fit and scaled success.

![The best strategies and ways of working for early-stage companies can lead to chaos and quality problems for mature companies. Similarly, early-stage companies that adopt mature ways of working can move too slowly and burn through runway.](https://static.fastertimes.cloud/post-attachments/pmf-strategy.svg)

If your business has yet to find a product-market fit, your primary goal is to find it. During this phase:

- Speed of product development is much more important than quality. Time to market is all that matters when you are still determining whether your product is useful to anyone. You will throw away much of what you build, so it's usually a bad idea to gold-plate your work.
- Individual customers have significant influence over the roadmap. You build new features to land specific deals in the sales pipeline.
- Product vision is highly fluid. While early-stage companies usually have a hypothesis about what they should build, new learnings typically have a significant impact on the long-term vision, which could change drastically before product-market fit.
- Any sale is a good sale. Before product-market fit, businesses rarely have a clear idea of their ideal customer, so any new lead is good enough to pursue.
- There is little need for process. During this phase, there is little consistency across the problems you tackle, meaning there is little need for standardised procedures. Small teams require less process because everyone knows everyone and works collaboratively.

After product-market fit, companies must scale their product into their target market. During this phase:

- Product quality becomes much more important. Moving quickly is still critical, but tech debt becomes a significant risk. Bugs aren't a big deal when you don't have any customers. When you have many, bugs become a severe concern.
- Priorities are set based on market needs. Individual customers can no longer have much influence over product decisions because this conflicts to satisfy the target market. The company is now building for the majority.
- Product vision becomes more opinionated. While flexibility about _how_ the vision is achieved is still essential during this phase, the vision must stabilise to give consistent direction and focus to the business.
- Sales teams become focused on targeting prospects that meet the ideal customer profile. You disqualify many more leads, and customers are less diverse.
- Standardised processes are required to deliver a good customer experience and achieve economies of scale (_i.e.,_ operational efficiency). As the team and customer base grows, the need to standardise how to handle everyday situations becomes clear.

To effectively make decisions, founders and product leaders need awareness of which of these two mindsets to employ. This knowledge is vital when you take advice from consultants and resources like books and blogs: most advice is only relevant before or after product-market fit is found. Applying feedback intended for mature businesses to your small-and-scrappy startup can be a real distraction while applying feedback intended for businesses still searching for product-market fit to a scale-up can lead to an unstructured, chaotic environment. For example, many early-stage companies agonise over technical debt and exhaustive employee onboarding plans when, as important as these things will soon be, they are currently an unnecessary distraction.

Tags: advice, startups, operations, strategy

# Find the best opportunities and solutions with divergent ideation

Premature convergence is the most common mistake I see startup leaders make. Premature convergence is where a team chooses a solution or even a problem to solve before considering all of their options. This usually leads to wasted effort on initiatives their customers or market don’t care about, and investment in solutions that don’t actually solve their chosen problems.

The principles of divergence and convergence can help leaders to understand and improve the problem-solving process.

1. Divergence is the act of turning one idea into many. Divergent activities expand and diversify the number of ideas or concepts available to you. 
2. Convergence is the act of narrowing down many ideas into one or a few most viable or appropriate ideas. Convergent ideas help you to determine which of your ideas or concepts is most important or valuable.

When you solve problems, create products, and build startups, it's crucial to employ both divergent and convergent strategies.

## Divergence, convergence, and problems

Before you build a solution, you must choose a problem to solve. Many startups are born out of the desire to solve a very specific problem, often already experienced or at least witnessed by the startup founders. This means startups initially have high confidence in the first problem they solve.

After this, however, startups struggle to identify additional problems they should solve. Many reflexively move onto problems that sound exciting but aren't crucial to their markets. These startups invest massive amounts of effort into low-value initiatives.

When looking for a problem to solve, startups should first employ divergent thinking. Don't leap into the first or most exciting feeling problem. Ask yourself: *how can I create a comprehensive list of the many problems we could solve?* Go through this process before you commit to any specific problem.

Activities that can help with divergent problem identification include:

- Market research, both data analysis and customer/prospect interviews.
- Reviews of feedback submitted by existing customers.
- Reviewing the reasons for lost sales. What features were missing? What problems did prospects want you to solve for them?

After you've accumulated a long list of problems you can solve, switching to a mode of convergence is important. When looking for a problem to solve, convergent thinking is about gradually narrowing down your list of opportunities until just one (or as many as you know you can juggle) remains.

Activities that can help with convergent problem identification include:

- Quantification of a problem. Use data to estimate the prevalence and impact of each problem. Common problems with low impact are generally low value. Rare problems with a high impact also tend to be low value unless you target a customer niche that experiences that problem especially often. You should prioritise common problems with a high impact above all else.
- Estimate the cost of doing nothing. How much money is your average customer wasting by ignoring this problem? How much money are they failing to make?

Always consider your confidence in your assumptions when prioritising your work. When two problems seem similar in value, lean towards the problem you're most confident in.

## Divergence, convergence, and solutions

After you've selected a problem to solve, it's time to find a solution. Many teams fail to meaningfully solve customer problems because they choose ineffective solutions. Most of the time, when a team chooses an ineffective solution, it's because they went with the most exciting or even the first idea they came up with. They failed to employ divergent thinking.

When looking for a solution to a problem, divergent activities help you consider various potential solutions before you select a winner. Example activities include:

- Silent brainstorms. Teams often brainstorm ideas out loud and in groups. This approach means dominant voices call the shots. If you brainstorm silently and individually (or in small groups), you give each person and each idea time for consideration. Some of the best ideas come from the quietest people.
- Low-fidelity solution sketching. If you outline ideas in too much detail, each potential solution requires a significant investment to explore. This biases teams against solution divergence. Low-fidelity sketching, like wireframes or literal paper/whiteboard sketches, is cheap and easy to produce, encouraging you to explore many ideas.

When looking for a solution to a problem, convergent activities help you to select the best solution for implementation. To converge on the right solution, teams need:

- A common understanding of what makes a solution great and what makes a solution poor. For many teams, this means roughly quantifying the effort required for each solution. Confidence in the required technologies or tools is another factor.
- Always ask yourself: *what is the minimum effort required to solve this problem for 80% of my customers/market?*
- The best solutions can be easily broken down into discrete implementation stages, each delivering legitimate value to customers. You should consider other approaches when a solution feels too difficult to break down.
- Customer feedback gathered through wireframe/prototype demonstrations and other user experience testing.

By starting with a simple and fast-to-implement solution, you can quickly validate your assumptions around the problem and solution. Always be biased towards getting something into the market soon.

## Premature and delayed convergence

Many teams fail to deliver meaningful outcomes because they converge on problems and solutions prematurely.

- If you prematurely converge on a problem, you may try to solve something that isn't very important to your customers or market. You also neglect all of the other problems you could've solved instead.
- If you prematurely converge on a solution, you may develop a solution that is dramatically more complex or expensive to build than some of the pathways you failed to consider. You may also implement a solution that doesn't even solve the problem you set out to solve.

Delayed convergence is equally as self-sabotaging.

- If you fail to converge on a problem, you may waste an extended period exploring ideas and fail to explore potential solutions. Many teams jump to a solution before fully converging on a problem. This premature convergence means different team members may have different ideas about the problem they're trying to solve, which can harm the solution.
- Failure to converge on a solution can similarly delay value delivery. It can also result in wasted resources as teams trap themselves in an endless mode of prototyping and hedging their bets.

Tags: advice, startups, strategy

# Manage cognitive load to build a productive startup

All startups are poorly resourced relative to their ambitions. This is why productivity is especially crucial to startups: a startup must punch above its weight to win. The negative impact of cognitive overload on productivity is well-established in research, but startup leaders rarely factor this into their strategy and operations.

Cognitive load refers to the mental effort expended when processing information or performing tasks. Simply put, it's the amount of mental processing power used at any moment​​. Much like a computer with limited processing capacity, our brains can become overwhelmed when too much information or too many tasks are presented simultaneously, resulting in cognitive overload. This overload can hinder learning, performance, and productivity, making it a critical aspect of employee experience[^1].

Cognitive load is naturally high in the startup environment because:

- Startups often require employees to wear multiple hats and simultaneously juggle various roles and tasks.
- Startup roles often involve quickly learning new skills, systems, or markets.
- The decisions made in startups often have significant consequences, which can increase the cognitive load involved in making those decisions.
- The fast-paced, ever-evolving nature of startups requires constant adaptation and change.
- The inherent risk and uncertainty in startups can create stress, which increases cognitive load.

This environment means startup employees are prone to burnout and reduced productivity.

## Reducing cognitive load

Roles, responsibilities, and tasks come with varying degrees of cognitive load:

- A task[^2] that requires multiple distinct decisions to be made has a high cognitive load.
- A responsibility[^3] that contains many distinct tasks has a high cognitive load.
- A role encompassing a diverse range of responsibilities has a high cognitive load.

The more information an employee must process at any given time, the less productive they will be. To lower the cognitive load in your organisation, make tasks, duties, and roles simpler for your employees:

- Break work into manageable chunks. The smaller a unit of work is, the easier it will be to deliver. 
- Prioritise tasks and responsibilities. By clearly prioritising your work, you can focus on a few high-impact tasks simultaneously, reducing the cognitive load. This is one of the best things a leader can do for their team.
- Automate what you can. Automation is especially crucial to engineering teams.
- Standardise recurring tasks and responsibilities. By establishing a standard process for recurring tasks, you reduce the number of decisions an employee must make to complete their work. This standardisation allows them to concentrate their cognitive resources on the task rather than the process, leading to more efficient and higher-quality work.
- Clearly define roles and responsibilities. Clearly defined roles and responsibilities eliminate ambiguity, reduce decision fatigue, and focus cognitive resources on the task. When employees know what you expect from them, they can better manage their time and mental resources, improving productivity and job satisfaction.
- Clearly define desired outcomes. When you focus on outcomes rather than outputs, you prioritise real return on investment instead of superficial progress.

While it seems like an abstract concept, cognitive load is an essential factor affecting productivity in all startups. Startup leaders who manage cognitive load for their teams build stronger, more productive startups.

[^1]: There is ample research on the impact of multitasking [on learning in particular](https://brandon.uno/links/594064966/).
[^2]: Example tasks: resolve a support ticket, write code for a feature, and perform an outbound sales call.
[^3]: Example responsibilities: recruiting, professional development, scoping out technical solutions, closing sales.

Tags: advice, startups, operations

# Developer velocity drives business growth

Rapid product development drives outcomes in startups. [McKinsey claims](https://brandon.uno/links/590365038/) that companies with great developer velocity achieve:

- Four to five times faster revenue growth.
- Sixty percent higher total shareholder returns.
- Twenty percent higher operating margins.
- Greater customer satisfaction, brand perception, and talent management.

The best way to improve developer velocity is to reduce the time developers spend on unnecessary manual work — when an engineering team moves slowly, it's usually because they're busy with work other than building software. In some startups, developers spend a tonne of time manually testing their work, reading bad documentation, manually releasing/deploying code, and troubleshooting issues.

![These two teams spend the same time developing software in each iteration. Because team two has a high degree of automation, they can get through two iterations in the same time that the first team can complete just one.](https://static.fastertimes.cloud/post-attachments/DevEx%20and%20Feedback%20loops%20Copy.svg)

## Reduce wait times

Software engineers spend a lot of their time waiting:

- They wait for tasks, tickets, or feedback from their product manager.
- They wait for their quality assurance testers to validate their work.
- They wait for slow automated tests to run.
- They wait for other engineers to review and merge their pull requests.
- They wait for the next release so they can ship their code.
- They wait for customers to upgrade to the new version so they can use their new features.
- They wait for the customer service team to relay customer feedback on their new features.

When developers wait, they either sit idly or work on something else. Both of these are terrible:

- Idle time is wasted time! Nobody wants key employees sitting around.
- Juggling multiple projects simultaneously kills focus, leads to excessive context switching, and distracts developers from what's important.

Startup leaders should prioritise developer experience to reduce wait times and keep developers focused on developing.

## Tighten feedback loops with automation

The best wait to improve developer experience is through automation. With automated frequent releases, developers no longer need to wait for their work to make it to production. With automated testing, developers no longer need to manually test their work or wait for someone else to do it.

[Startup leaders who prioritise automation through DevOps build more productive teams](/post/devops-or-product-management/). 

- Automatically build your software upon each commit or pull request with Continuous Integration (CI) tooling.
	- Automate testing. Automated tests are more reliable and efficient than manual tests because they reduce human error and run in the background. Your build process should run automated tests.
	- Automate performance testing. Software can stress test your application and infrastructure for you.
	- Automate static code analysis, dynamic analysis, and dependency checks to reduce the burden of cybersecurity compliance.
- Automate releases and upgrades. With Continuous Deployment (CD), developers no longer need to manually release code and upgrade customers. You can deliver value frequently with minimal overhead.
	- Use automated migrations to handle database schema changes.
- Manage infrastructure as code. With infrastructure as code, you can automate platform infrastructure provisioning, configuration, and management.
- Automate monitoring, logging, and alerts. Proactive monitoring of infrastructure and services can reduce the number of unexpected disruptions, distractions, and incidents.

## Cut out intermediaries to tighten feedback loops

After a feature is released, additional work is usually required to improve it. Customer feedback and the measured performance of the feature (adoption, load times, conversion rates) informs this work. Developers spend a lot of time waiting for this feedback (though they may not realise it because they typically move on to something else while they wait).

While insulating developers from unnecessary distractions is a good idea, leaders often take this too far by adding distance between engineers and customers. Product people often toil over processes and research/communication efforts to help engineers understand customer feedback and customer needs. There is a simpler solution here: expose engineers to customers.

A good software development process features customer feedback at every stage. Engineers should consult quantitive customer data and qualitative anecdotes directly from customers. This exposure doesn't mean every customer should have constant direct access to engineers; developers must focus on development. But as they build, they should demo and deploy directly to customers who can provide valuable feedback and advice.

## Maintaining short wait times

Teams that win over the long term continuously shorten developer wait times. Startup leaders should regularly ask themselves what roadblocks, barriers, and distractions keep their engineers from building software. Try to measure this, and ask your developers for feedback. The less time developers spend waiting, the more they spend building. That's how you outpace the competition and deliver value to customers.

Tags: advice, startups, operations

# Great startups are idea meritocracies

Most organisations make decisions based on hierarchy and position, so teams simply execute their leaders' vision. In an idea meritocracy, opportunities are pursued based on their merit. Startups work best as idea meritocracies because they are idea-rich and resource-poor — prioritisation is crucial. Even a startup that expertly executes will fail if its strategy is flawed. Ray Dalio, the creator of the largest hedge fund in the world, coined this concept in his book *Principles*.

In an idea meritocracy, all people raise ideas, regardless of their position. Customer success employees raise product ideas; accountants suggest new ways of working to support teams; product managers recommend pricing strategy changes; junior staff submit ideas with managers from other groups; and customer service staff uncover content marketing ideas. People need to feel empowered to raise their voices for this to happen.

- **Encourage detachment from one's ideas.** If you view your ideas as part of your identity, you will take it personally when others criticise or debate them. While tact can help here, it's also vital for individuals to treat their own ideas with the same detachment they apply to other people's ideas.
- **Recognise (and never punish) idea sharing.** Celebrate the act of raising ideas. Never make someone feel bad for speaking up, no matter how terrible their concept is.
- **Let new ideas breathe.** Enthusiasm for an idea starts high and fades over time. It's easier to honestly debate the merits of an idea after the initial enthusiasm has worn off.
- **Keep track of ideas.** It will feel pointless to raise new ideas if they tend to fall by the wayside. You don't have to act on every idea (in fact, most ideas should fail), but every idea should receive some consideration and constructive feedback.
- **Create a well-informed organisation.** The best ideas are grounded in fact and reason. Collect the data you need to inspire new ideas and ground debates in reality.

An organisation with freely flowing ideas has many more opportunities to consider than an organisation where most ideas come from management. To create an idea meritocracy, you need a way to determine the value of each idea so that you can focus on what will most move the needle.

- **Standardise where ideas live.** In an idea meritocracy, all teams receive many inbound ideas, which can be challenging to manage. [Keep these in a queue for each team and manage them transparently](/post/reduce-stress-and-get-more-done-by-pushing-work-into-queues/).
- **Standardise how you present ideas.** A common way to outline ideas makes evaluating and prioritising ideas easier. Additionally, if you expect leaders to respond to all ideas, it's only fair to expect those with ideas to put some effort into outlining them. [I recommend an outcome-focused one-page document for every idea](/post/defining-initiatives-with-at-outcome-mindset/).
- **Standardise how ideas are evaluated.** For the best ideas to win, you need to know how good each idea is. In some cases, this comes down to a science: measuring conversion rates and revenue is easy. In others, it's more of an art: it's challenging to quantify the impact of some features before you build them. Think about what research, ideation, and general rigour you expect each idea to go through.
- **Encourage (and make time for) rigorous debate.** [Debate is the best tool to evaluate the quality of an idea](/post/use-debate-not-votes-to-achieve-census-in-your-strategy/). For many people, this feels confronting at first, but a culture of healthy debate is the best way to come to quality decisions.

In an idea meritocracy, we frequently do the hard work to evaluate, teardown, and debate ideas. For the uninitiated, this can be an uncomfortable experience. But we achieve great outcomes by embracing this discomfort.

Tags: advice, startups, strategy

# The return to text interfaces will be temporary

Many computer users are too young to remember, but in the early days of computing, all software was text-based. Users typed commands into a terminal, and results were displayed as text. Fortunately, we moved away from this, building specialised user interfaces for virtually all applications, and up until recently, text-based user interfaces were a relic of the past for most users.

Well, text-based user interfaces are back in vogue thanks to ChatGPT, and to many users and builders, this is disappointing. Why would we want to throw away our long history of graphical user interfaces for inferior, difficult-to-use, text-based interfaces?

ChatGPT has a text user interface because the inputs and outputs are too diverse to predict. This is because it is a massively generalised tool (it can do a lot of unrelated tasks) and its inputs and outputs are probabilistic (the input incantation does not have to be specific, and the output will vary every time).

For example, the output of a request to an AI assistant could be a booked flight, hotel options to choose from, an edited essay, a movie that requires a little fine-tuning, a functioning website, suggested restaurants on a map, directions, video instructions for a recipe, or the meaning of life. All of these outputs (and their corresponding inputs) require very different user interfaces.

It's impossible to deterministically design a user interface for a truly generalised, probabilistic tool. There are simply too many variations of input and output to do this in a deterministic (i.e., pre-planned) way[^google]. Asking a UX designer to do this is equivalent to asking them to open up Figma and, in a single file, design every single app that has ever existed and will ever exist in the future. They will be there for eternity.

So, are we doomed to text interfaces for the rest of our lives? Is chat the ultimate form factor? Absolutely not.

The solution to probabilistic inputs and outputs is probabilistic UIs. Future versions of ChatGPT (or whatever replaces it) will generate results and then generate a custom user interface to best display these results. Our phones (and future devices[^smartglasses]) will no longer be defined by pre-installed apps and features. Instead, these will morph and evolve with each use[^customisation], based on what our device decides we need to see/do to get our work done. This will make the current paradigm seem prehistoric. 

This paradigm shift makes me more bullish on native mobile apps, as I expect the LLMs that undergird this functionality to run on device. It also, obviously, makes me more bullish on on-device AI and the future ability for anyone to get just about any "real work" done from their phone. Lastly, it probably makes almost all SaaS apps moot, apart from ERPs/CRMs, as they will house the corporate cloud data and deterministic logic/rules that undergird the business versions of these apps. Eventually, they may not have UIs of their own at all.

The mobile era started to shift all workloads to tiny handheld devices, supported by centralised clouds. But not all problems could be solved on a small screen, limiting the full potential of this transition. I think LLMs will reaccelerate this transition and take it to its logical conclusion: a world where we probably don't need bigger devices at all (and the AR future originally promised by Google Glass).

[^google]: Google has tried to do this with their search results in recent years, where certain results will be represented in a much richer way than just some blue links. But they've barely scratched the surface when it comes to the total number of possible graphical representations of search results.
[^smartglasses]: This concept is particularly compelling for augmented reality interfaces which will present in front of our eyes the minimum effective UI to solve our problems.
[^customisation]: One thing I'm excited for is the ability for users to customise these user interfaces on demand. Don't like the way the navigation works in your writing app? Ask your device to rearrange the UI for you.

Tags: advice, startups, ai

# Empower teams with measurable goals

Startups can take a long time to find their feet. The best ideas can be challenging to build. And, even with a product ready to sell, you still need to find the best way to bring your product to market. Early startup recruits often fail. When growth takes off, a startup could be on its fifth salesperson, fourth marketing manager, third customer success manager, and second product manager. 

While some recruits fail because they cannot deliver results, many fail because of unclear goals. This confusion is why it’s so important for founders to define clear, measurable, and achievable objectives for their teams. 

Ideally, you should outline these before you hire (we hire to solve specific problems, after all) so that you can communicate them during the recruiting process. When you know what success looks like, it’s easier to get there.

## Set measurable goals

A simple and measurable target leaves no ambiguity. So, startup leaders should set goals for the team to measure and move. Growth teams, for example, have two goals: find and close opportunities. So, their most important KPIs are:

- The number of high-quality leads/opportunities they can find.
- How much future revenue can they win the business (by converting leads into customers)?

Someone needs to be accountable for each of these goals in every business. Marketing or outbound sales typically find leads while (inbound) sales close them. Sales own both when salespeople are responsible for finding and closing their opportunities. Marketing holds both for self-service/bottom-up growth models where customers typically sign up without talking to a salesperson.

While lead attraction and revenue growth are the KPIs that matter most, mature teams measure more than these two numbers. Conversion rates between sales stages, for example. Teams might also evaluate salesperson performance based on how customer outcomes. For example, sales leaders expect a low percentage of new customers to churn within the first year, and if you track this by salesperson, you can evaluate the quality of each deal. When churn is high for a particular salesperson, this could indicate they prioritise leads poorly and oversell the product.

All teams within a startup should have some KPIs:

- Each customer support agent needs a daily, weekly, or monthly target for customer support cases. Measure support quality through time-to-first-response and customer satisfaction scores—benchmark support agent performance based on the top performers in the team.
- Finance teams should track financial KPIs such as cash position, accounts receivable aging, and prompt payroll.
- Employee engagement/eNPS, employee turnover rate, time-to-fill positions, admin cost-per-hire, and absenteeism should be tracked by HR teams.
- The most crucial measure for early-stage product development teams is iteration speed. Startups need to experiment their way towards product-market fit, and the faster they move, the sooner they’ll get there. Measuring this is more art than science: ask your team to set aggressive delivery goals and regularly grade their own performance. Mature product-development teams are often easier to measure, as they will likely own areas of the product for the long term. For example, a team working on a customer sign-up workflow could measure conversion rate improvements over time.
- Quantify customer success team performance based on expansion revenue, customer retention, and customer satisfaction.

One benefit of measurable goals is that they are easy to incentivise. Pay salespeople commissions based on their revenue, and pay bonuses to other team members based on their respective KPIs.

## Ensure your team can move the numbers

To achieve great results, people need control over what they do and be motivated by tangible business outcomes. Effective delegation requires a balance of these two forces, [a topic I’ve written more about already](/post/how-accountability-enables-autonomy/).

Only hold people accountable for delivering outcomes that they can control:

- A salesperson with no top-of-funnel responsibilities can’t be expected to win revenue without any leads in the pipeline.
- A product manager who does not control engineering hiring and resource allocation should not be accountable for delivery timelines.
- A marketing manager should not be expected to ramp up lead numbers if they have no say in product positioning and targeting.

When you set the goals for a role, make sure your expectations are reasonable, given the amount of control a person has over what they do and how they do it. Hold employees and teams with absolute autonomy to a high standard, with broad and ambitious expected outcomes. Groups and individuals with very little autonomy should have appropriately scoped KPIs.

## What happens when we fail?

It’s essential to reflect on your progress relative to your goals frequently. If a team or individual repeatedly fails to deliver, you have a few options:

- Help the team. Ideally, everyone can achieve great things independently. In reality, most teams need guidance to achieve their goals. 
- Adjust the goal. If you discover your targets are unreasonable, you might need to lower your expectations.
- Try again with a new team. Sometimes, people aren’t cut out for their current role. This reality is inevitably painful for everyone involved, but your primary role as a startup leader is to find the right people to grow the business. If, at first, you don’t succeed, try again. It’s better to make this decision quickly than to lose many months of progress deliberating.

Founders willing to make tough resourcing decisions quickly are more likely to succeed than those who dither. This is the uncomfortable reality of any leadership role.

Tags: advice, startups, operations, people

# Reduce stress and get more done by pushing work into queues

Cognitive overload plagues startups. People frequently bombard you with problems, ideas, questions, complaints, and requests. You have many more problems to solve than you do with resources at your disposal. This describes every role at most startups and leads to a feeling of chaos and disorganisation, making burnout a matter of *when* not *if*.

One tactic that works for individuals and teams is to centralise requests and ideas into queues[^1], which you later prioritise, schedule, and complete. This is a simple and old idea. Customer support teams usually work out of support queues, and many engineering teams maintain backlogs, so to many, this may seem like a painfully obvious suggestion. But it is a powerful and underrated principle for personal productivity and business operations that applies to all teams.

## The mechanics of an inbound work queue

Some requests are easy to action at the moment, but many tasks require a good amount of focus to tackle. A queue can be where you keep these inbound requests and other work. 

1. When you receive a request or have an idea, resist the urge to action it immediately (unless it is truly trivial) and instead put it in the queue.
2. Next, establish a habit of regularly tidying up and prioritising this inbox. This is where you consider the urgency of each task based on expected outcomes.
3. Lastly, you need a ritual to schedule prioritised work from your queue. This could be as simple as moving things to your to-do list (later, we'll discuss more complex mechanisms for teams).

When you centralise your work into an inbox, you decouple the request from the response. This has positive effects:

- **Reduce busy work and deliver outcomes.** You can prioritise your work based on expected impact or urgency rather than when it was brought to your attention. This empowers you to be more intentional about your work and should deliver better outcomes.
- **Reduce noise and maintain focus.** When you remove the need to tackle requests immediately, you dramatically reduce the cognitive load of new requests.
- **Provide a holistic view of your work.** Most of us receive requests from several people and systems (*e.g.,* Slack, email, action items from meetings). When you keep all substantial requests in a single backlog, you can work with more clarity.

My personal inbox lives inside my to-do app[^2]. My inbox contains action items from meetings, complex requests delivered via Slack or email, new ideas, and more. I reprioritise my inbox every Monday and schedule some tasks for the week. 

## Practical examples for teams

Teams should funnel all inbound work (that they can't immediately tackle) into a shared backlog. If you receive many requests, create a simple request form that your colleagues or customers can use to easily push work into your inbox[^3].

Here are some practical examples of what might live in team backlogs:

- Support teams: customer tickets, internal escalations, and quality assurance requests from Product. Support teams should receive all inbound work into their help desk software and frequently reprioritise and allocate tickets.
- Product development teams: ideas, feature requests, product feedback, bugs, incident reports, and escalated support tickets. This work usually lives inside an issue tracker (like Jira).
- Marketing teams: landing page requests, case study opportunities from customer success, website issues,
- Operations teams: operational ideas or complaints, requests for access to systems or data.
- IT teams: hardware and software support requests, cybersecurity incident reports.

While the fewer, the better, sometimes, it makes sense for a team to have multiple queues for a team. For example, a product team might capture customer feedback in a dedicated inbox because the volume of feedback received would clog up their primary work queue. Whenever you split inbound work into a separate backlog, it's critical to also establish inbox review and maintenance rituals. Every backlog needs regular attention, though the frequency for each may vary (you might review your core inbox every week while you review your backlog of customer feedback once a month or quarter).

[^1]: Pushing requests into an inbox for later processing is a very old idea, but Getting Things Done, developed by David Allen, is the most well-known framework that employs this concept. 
[^2]: I use [*Things* by Cultured Code](https://culturedcode.com/things/) as my to-do app. *Things* is [designed around the idea of a centralised inbox for tasks](https://culturedcode.com/things/support/articles/6378414/), though you can use just about any to-do app in this way.
[^3]: Most [help desk](https://support.zendesk.com/hc/en-us/articles/4408846913050-Options-for-letting-end-users-submit-tickets-with-forms) and [many issue tracking](https://support.atlassian.com/jira-work-management/docs/what-are-forms-and-what-can-they-do/) softwares allow you to receive requests via a form. [Zapier is another solution](https://zapier.com/apps/categories/forms) for this.

Tags: advice, startups, operations

# Tighten enterprise sales cycles with bottom-up growth

Large organisations buy slowly, especially when buying critical components of their digital architecture[^1]. These long sales cycles are why enterprise selling is so expensive: the more time and effort each sale requires, the more you spend resourcing that sale[^2]. It takes time to convince a large organisation to adopt your product.

Bottom-up SaaS is a sales strategy that targets individual users or teams within an organisation rather than the organisation as a whole. The goal is to sell to some individual users first and then upsell the broader organisation later. Bottom-up growth is excellent because:

- It enables individual users to adopt your product and pay you for it without the endorsement of their leadership team. This situation should accelerate logo growth (though each new customer will pay you less at first).
- It delays the tough conversations with CEOs, CIOs, CTOs, and other leaders. When you speak to them, they already have employees or teams getting value out of your product. These internal advocates can help you prove your product's value and close the deal.
- It turns the sales process into more of an upselling process. In many cases, customers know the value of your product by the time you talk to them. Rather than sell the benefits of your core product, you sell the benefits of an enterprise license with specialised features and improved security.

## Is your product suitable for a bottom-up strategy?

Shorter sales cycles sound great to any founder, but not all products suit a bottom-up strategy. Characteristics of suitable products are:

- Atomised value. Products must be valuable to individual users and teams. Some products are only useful to independent users if their entire organisation use them[^3]. It's easy for an employee to adopt their own to-do list app, but an accountant can only adopt accounting software with the cooperation of their organisation. Some products must be bought by an entire organisation to work.
- Self-serviceability. Barriers to entry will block bottom-up adoption if users cannot independently adopt, configure, and use a product. If customer service or professional services are required to adopt a product, individuals cannot adopt it without enterprise buy-in[^4].
- Progressive or freemium pricing. Organisations rarely empower individual users and small teams to purchase expensive tools without approval, so pricing is critical to bottom-up sales. Products should be cheap enough for a small team to buy, but pricing should scale to fairly monetise enterprises when they fully convert.

Companies that can't rely on bottom-up sales due to the nature of their product can create side effects or tools to attract customers and generate interest. These side products are typically free or low-cost, easy to adopt, and provide value to a broader audience. From here, they upsell their core products[^5].

## The bottom-up customer journey

Regardless of their sales methodology, marketing teams should only target individuals who can actually purchase their product. SaaS companies with traditional enterprise sales strategies target CEOs, CIOs, CTOs, and heads of department in their marketing efforts because these are the people with the power to buy. Anyone can adopt a bottom-up SaaS product, so these marketing teams tend to target individual users instead. The needs of buyers and users can be dramatically different[^6], so messaging for bottom-up marketing campaigns look very different to traditional enterprise marketing.

Salespeople who sell SaaS to enterprises spend most of their time talking to those buyer personas (CEOs, CIOs, CTOs, and heads of department), regardless of their growth strategy. It might be easier to sell to individuals, but if you want to land large contracts, you usually need to sell to the executives eventually. In the traditional enterprise SaaS model, salespeople sell upfront: they work with prospects yet to adopt their product. In bottom-up SaaS organisations, salespeople mainly sell to existing customers. They reach out to self-service customers, find out who they need to speak with to bring the entire organisation into the fold, and sell from there.

Customer success is critical to both types of startups, though bottom-up companies tend to focus more on upselling, while traditional SaaS may concentrate more on renewals and retention.

[^1]: Enterprise sales cycles are long because it takes time to demo, build trust, and prove value to all stakeholders. Even the perfect pitch can be delayed by compliance and budgetary approvals.
[^2]: It is also costly to lose a deal you've invested a tonne of effort into, making enterprise sales cycles quite wasteful.
[^3]: Like almost everything, this is a spectrum. A time-tracking app is helpful for individual employees and better for whole teams and organisations. Slack is useless for individuals, useful for small teams, and great for large organisations. An inventory management solution is futile unless an entire warehouse adopts it.
[^4]: Enterprise SaaS companies tend to offer professional services to compensate for usability challenges. This can make it difficult to transition to a self-service model, as they may need to rebuild the entire onboarding experience.
[^5]: Atlassian uses Trello to upsell Jira. Adobe uses its mobile apps, like Spark, to upsell its professional suite. HubSpot offers a variety of marketing tools to upsell their CRM. Note that while this is a great way to acquire leads, it can be a dangerous distraction for early-stage startups.
[^6]: While users want to get their work done and have a pleasant time doing so, buyers care more about security, reporting/analytics, and cost.

Tags: advice, startups, sales

# When’s it too late to enter a market?

First-mover advantage argues that businesses first to enter a market have an advantage over latecomers. This common-sense idea discourages prospective founders, giving them the impression that they are too late to tackle a problem they've identified because someone else got there first. While first-mover advantage exists and has helped some projects establish a lead, there are many counter-examples where very late market entrants have won. In fact, the benefit of being late into a market often outweighs the costs.

If you start a race before your opponents are even on the track, it is logical to expect to come first. But races are poor metaphors for startup and technology competitions. One flaw in this metaphor is that while races have a finish line (once you win, you win), technology competition is ongoing. Some argue that startup building is more like a marathon, but even marathons end. New technology frequently disrupts dominant incumbents of many decades in many markets. A technology race ends only when a new invention renders all players redundant. 

In the 2010s, many eagerly watched Sketch, a new MacOS-native application for UX designers, disrupt Adobe's monopoly in digital design. Their hypothesis was simple: no Adobe application was designed with web or app design as a primary use case. If they could build a new specialised app from the ground up for this market, it would be radically better than Adobe's generalised designed tools. The secret that undergirded their startup was that the digital design tools race was not over.

Adobe responded to the threat of Sketch with a copycat product. They built a specialised desktop app for the digital design market, but their head of product recently declared this effort a failure. Adobe did not fail because Sketch had a first-mover advantage in the specialised digital design market. They failed because yet another entrant came onto the scene, and they did things completely differently. While Adobe focused on replicating the success of Sketch, Figma reinvented the market again with a cloud-native solution engineered for a multi-player user experience from the ground up. The secret that Figma stumbled upon was that digital design is inherently collaborative, so a radically collaborative solution would invalidate the competition. This new approach was so radical it threatened to disrupt Adobe's other products enough that they were willing to pay twenty-billion dollars to acquire Figma[^1]. Two upstarts reinvented this market in less than a decade by deploying differentiated strategies. The only luxury first-mover advantage afforded anyone was the pocketbook to purchase the competition (something I'm sure Figma shareholders are pleased with).

Like a race, speed is critical to technology competitions. The party that can most rapidly improve[^2] has an advantage, which certainly helped Figma. Another lesson from the Adobe example is that, unlike a race, innovation can completely and unexpectedly reset, which has pole position overnight. A single innovation from a competitor can render a leader's advantage moot. Sketch and Adobe may have been hurtling towards the finish line, but Figma moved the finish line to an entirely new location. They both had to start again to win in this new world. Whenever this happens, startups have an advantage because the bigger the ship, the more difficult it is to turn around. The greater your previous success, the more effort it will take to reinvent your approach.

The best argument in favour of first-mover advantage revolves around network effects. Network effects describe a situation where the value of a product is tied to the number of users it has. The more people use Uber, the more opportunities drivers have to make money. The more money drivers can make, the more attractive to drivers the marketplace is. The more drivers there are on Uber, the better the service will be for passengers (greater supply leads to lower costs and better service). Network effects are challenging to get off the ground, but they can rapidly build momentum and entrench market leadership. A startup would struggle to challenge Uber today because drivers and passengers are incentivised to stick with Uber due the Uber's scale. Perhaps an incredibly well-funded startup could pay drivers enough to overcome this cold-start problem, but the tide is against them. Technological innovations transforming market dynamics are usually required to disrupt a company with powerful network effects[^3].

In the early 2000s, Apple, Sony, and others fought fiercely for the MP3 player market. This race didn't stop because Apple won — it stopped because the invention of the smartphone rendered MP3 players entirely irrelevant. A recent and more speculative example is Google: while they have an absolute monopoly in search, and it seems ridiculous to expect a new entrant to beat them in search, many expect the likes of ChatGPT could dramatically reduce the importance of search, disrupting Google along the way.

Being late to a market affords several advantages. Most obviously, you can see what works and doesn't work by observing the experiments of your competitors — first-movers tend to waste a lot of capital on ideas that don't pan out. Late entrants will have an easier time selecting technologies and commercial strategies most likely to work. This is the Apple playbook: enter late with the best product.

Your strategy is probably undifferentiated if you compete with an established business and feel like you can't win because they have more resources or a monopoly on customer attention. If you copy the playbook of whoever is winning the market, you will build an artisanal and mediocre version of what customers can get elsewhere. Differentiation is required to succeed in an established market. Find a way to do things differently. The best way to do this is through new technology disrupting the conventional approach. Another way is to start in a niche: even the most prominent companies cannot create the best solution for every niche covered by their product. If you build something highly specialised, you can satisfy your base better than any juggernaut. From here, you can expand to other niches, and you may discover the next disruptive technology for your market along the way.

[^1]: [Adobe acquires Figma for US$20b](https://news.adobe.com/news/news-details/2022/Adobe-to-Acquire-Figma/default.aspx).
[^2]: Rapid improvement is about rapid change that has a meaningful, positive impact on business prospects. Superficial change is unhelpful.
[^3]: Many have speculated that self-driving vehicles will disrupt Uber. An automaker with a self-driving technological advantage like Tesla could deploy a fleet of cars that don't need drivers, radically lowering the costs of taxi-style transport. They could refuse to sell these vehicles to Uber and quickly flip the market dynamics in their favour. This threat is why Uber has invested in self-driving technology.

Tags: advice, startups, strategy

# The value of a contrarian startup hypothesis

You start a startup when you believe you can find a viable solution to a valuable enough problem for a big enough market. Whether defined explicitly or not, behind every startup is a hypothesis like this. Some startup hypotheses are low risk because they contain confident assumptions. When a startup contains high-risk assumptions, believing in the undergirding theory is challenging. If your target market is tough to define and access, perhaps because nobody has targeted this market before, it won't be easy to sell to them. If the problems they face are challenging to identify and understand, finding the most crucial problem to solve will be difficult. If novel, untested, and poorly understood technologies are required to solve your chosen problem, there is a high chance that you won't be able to deliver a solution.

|                   |             Conventional hypothesis             |        Contrarian hypothesis        |
|-------------------|-------------------------------------------------|-------------------------------------|
| Market            | Easy to access.                                 | Tough to define and access.         |
| Problem           | Obvious and common.                             | Emerging or difficult to pinpoint.  |
| Solution          | Obvious and achievable with off-the-shelf tech. | Requires novel technology.          |
| Competition       | Crowded markets; easy to copy.                  | Nascent markets; difficult to copy. |
| Payoff if correct | Mediocre.                                       | Extreme.                            |

The less risky a startup strategy is, the more copyable it is. So, low-risk markets are crowded. Whether it's the problem you tackle, the solution you offer, the market you target, or the technology you build, building a startup around a contrarian worldview will make your strategy look crazy to outsiders. They will think you are wasting your time; nobody will buy your product. For many startups, the outside perspective is correct, and they fail. But startups when these startups succeed, they succeed big. Peter Thiel claims that all great startups are founded around a secret:

> Every great business is built around a secret hidden from the outside. A great company is a conspiracy to change the world; when you share your secret, the recipient becomes a fellow conspirator.
> 
> There are two kinds of secrets: those about nature and those about people. Natural secrets involve science, and their discovery can lead to important technological breakthroughs. Secrets about people are different – they involve things that people don't know about themselves or what they want.

## Startups with big secrets

Airbnb is the perfect example of a startup built on a seemingly ridiculous hypothesis. The "secret" hypothesis behind Airbnb is the realisation that people are willing to rent out their spare rooms or homes to strangers and that travellers are happy to stay in a strangers' home. The founders of Airbnb discovered that there was untapped value in people's unused spaces and that the conventional wisdom that people wouldn't want to lodge in a stranger's home was incorrect.

Of course, the idea behind Airbnb seemed ridiculous until it didn't. And now, it is ubiquitous. Companies like Airbnb can thank their contrarianism for the following:

- More runway before others try to copy them. If people are skeptical of a business, they are unlikely to copy it. This runway can give startups time to achieve an advantageous lead in the market. If, like Airbnb, a company benefits from network effects, this lead will be especially tough to disrupt.
- Defensible technical or commercial moats. If a business is difficult to build because the market is hard to crack or depends on novel technology, those who copy it will have a hard time[^1].
- Surprisingly large addressable markets. When a startup enters an existing market, it is relatively easy to see how much opportunity there is. When one enters a previously neglected or undefined market, the market could become much larger than expected. Airbnb and Uber both had this[^2]. Investors and analysts quantified their total opportunity based on the existing hotel and taxi markets, respectively. But, by reinventing how these *jobs to be done* could be achieved, both companies tackled untapped demand more than existing demand. This market expansion is why taxis and hotels still thrive in many markets.
- Impact on the world is more dramatic and unclear. When a startup optimises an existing solution, it incrementally improves productivity. When it deploys a truly novel technology, it creates new economic activity that can dramatically change business models and consumer behaviour[^3]. The more a startup changes the world, the more value it can capture[^4].

## Conventional wisdom machines

Information has rapidly become cheaper to distribute, store, and consume thanks to the printing press, the telegram, radio, television, cable television, the internet, search engines, and social media. The implications of these technologies have driven many of the major world events in modern history. Today, information costs are effectively zero. You can download the entirety of Wikipedia onto your smartphone. You can even run a large-language model on your smartphone if you're savvy.

Now that the world's information is at our fingertips, it is incredibly easy to become acquainted with conventional wisdom on any topic. Wikipedia, where users aggregate and summarise the contents of the internet, was the first great conventional wisdom machine; ChatGPT is the ultimate one[^5]. It can essentially generate a Wikipedia entry for any topic you want, even if the existing content on the internet hasn't presented knowledge in the way you've requested before. Wikipedia is artisanal ChatGPT — a quaint attempt to manually create what LLMs can create automatically.

These tools are helpful because, most of the time, conventional wisdom is what you want. When seeking medical or legal advice, the best answer is usually the generally accepted answer. General expertise is now free.

## Value of differentiated thinking

When you build a startup, you need more than just conventional wisdom. Conventional wisdom never contains those secrets that lead to significant innovations.

When most of the world was information poor, you could create big businesses by copying other people in other locations. An entrepreneur inspired by the New York Times could copy the New York Times without competing with it by simply launching in new geographies. This duplication was done by leveraging privileged access to conventional wisdom. Now, everybody has access to this knowledge. As the internet destroys space and time, many companies are digital, and digital companies are increasingly global because customers are easy to access from anywhere.

The globalisation and democratisation of knowledge and markets, coupled with AI Copilots, means divergent thinking is more valuable than ever. When everyone can be an expert on the conventional view of any topic, ideas that go against convention (and turn out to be correct) are even more advantageous. When anyone can ask an AI for the best way to achieve something, people with a better answer are precious. Most contrarians are wrong, but when they're right, they're rich.

There are a few implications for this:

- Differentiated data is more valuable than ever. If your startup has privileged access to knowledge that commodity AI tools have not trained on, you can leverage this data to make correct contrarian decisions. A model is only as good as its data set, after all.
- Specialisation is once again wise for startups and individuals alike. AI tools empower everyone to be a generalist at nearly everything. Specialists are more likely to know what the consensus gets wrong.
- Even correct contrarians should embrace standard practices, and therefore AI tools. You differentiate your startup by doing things differently in the places that matter. But not everything matters equally. Sometimes, convention will suffice (especially if it is cheap).
- AI tools are a great way to strengthen contrarian arguments. The better you understand consensus, the better you can challenge it. ChatGPT is currently the best tool in the world for understanding conventional wisdom. Innovators should learn about conventions to find opportunities to go against the grain.

> *"All models are wrong, but some are useful."*
> 
> — George Box

The current generation of AI tools cannot run every aspect of your startup. But in areas where conventions are good enough, AI can run the show. In areas where differentiation is required, AI will remain a useful tool, but defiance of the convention should be the goal. One day, AI models might be advanced enough to independently uncover the secrets that begat great businesses. Until then, they have only increased the value of the most important natural resource for innovation: secrets.

[^1]: This can backfire if you fail to recruit the best technical talent for your solution and competitors build even better technology.
[^2]: Many Airbnb and Uber use cases do not overlap with hotel or taxi use cases. This untapped demand is why introducing these products expanded the overall market. Even if the founders and investors believe their goal is to disrupt incumbents, truly novel technologies often create new markets more than they disrupt what exists.
[^3]: Another way of saying this: some technologies disrupt incumbents, while others disrupt whole industries and society.
[^4]: Many startups change the world but leave others to capture the value they create. ARM, for example, is a world-changing company in the semiconductor industry. But most of the value they've created has been captured by TSMC and Apple. With a better pricing strategy, they could be a more successful business.
[^5]: This is why articles written entirely by ChatGPT are not very compelling yet. They regurgitate information that readers can find elsewhere. For some purposes, that might be good enough, but differentiation is too valuable for many.

Tags: advice, startups, ai, strategy

# Don’t charge extra for single sign-on

When your customers suffer a cybersecurity breach, it is often the result of poor password or user management. Users might irresponsibly store, share, or reuse passwords, administrators may forget to disable accounts for former employees, or users could fall for a phishing attempt and give their login details to an attacker by accident. Passwords are a major point of failure in the realm of cybersecurity, and yet they remain the most common form of authentication employed by software-as-a-service products.

The best way to reduce password and user management risk for your product is to eliminate passwords altogether. There are a few ways to achieve passwordless authentication today, and all SaaS businesses should support one or more of these methods on all plans.

## Single sign-on

The most obvious way to enable authentication without passwords is single sign-on. Single sign-on is a technology that allows users to log into your SaaS application with their account from another SaaS application. For example, in a world where all SaaS apps support single sign-on, businesses that use Microsoft 365 or Google Workspace[^1] could enable their employees to sign into all apps using their Microsoft 365 or Google Workspace account. This dramatically simplifies password management for users, making it easier for them to manage credentials responsibly. 

Automated account provisioning and de-provisioning are added benefits of single sign-on. As long as an employee has an account with the identity provider, they should be able to access each SaaS app that supports single sign-on (and has permission to access). This goes the other way too: when an employee loses access to their account because they have left the company, their access to peripheral SaaS apps is removed too. It is common for small businesses to forget to disable accounts for staff, which can pose a serious cybersecurity threat.

## Email-based authentication

Email-based authentication (also known as magic-link authentication) is a flow where users can access an application using only their email address. In this flow, users enter their email address, after which they are emailed a soon-to-expire link that they can click to instantly login.

This flow is easy to implement and successfully eliminates passwords from the flow. In a roundabout way, it can also automate provisioning and de-provisioning: access can be enabled based on the domain of their email address (*e.g.,* you can only access a McDonald's portal with an `...@McDonalds.com` email address), and if their email account is disabled, they won't be able to receive the magic link anymore.

## Web Authentication

Web Authentication is a new open standard that ties access permissions to a user's device, often using biometrics (*e.g.,* facial recognition or fingerprint). Essentially, a user's phone or laptop works with the application to determine who the user is and whether they should have access. Apple and Google tie this to your iCloud and Google accounts, respectively, which allows you to access Web Authentication accounts from all of your devices.

This is a fantastic authentication method for B2C apps because the authentication flow is effortless for users, and most users keep their iCloud or Google accounts for a very long time. This method is limited for B2B applications, though, because personal iCloud and Google accounts are rarely managed by an individual's employer (though I'm sure the various single sign-on providers will find a way to offer a pleasant user experience for Web Authentication eventually).

## Why you need to offer one of these methods free of charge

It is now common for B2B SaaS applications to charge for single sign-on (if they offer it at all). This can cost customers hundreds of dollars per month per SaaS application. While this practice might help SaaS companies to better monetise their large customers who require single sign-on, it forces small and mid-sized businesses to compromise their security practices. These costs rarely align with the cost of providing these features.

- Atlassian has [a dedicated product for single sign-on](https://www.atlassian.com/software/access/pricing) (bundled with some other security features) that it charges at least US$30 per month per user for.
- Slack restricts single sign-on to Google on the [cheapest paid plan](https://app.slack.com/plans/T030XTLMFBP)[^2]. I suspect this is related to Microsoft Teams being a competitor. Microsoft's anti-competitive behaviour doesn't make this any less user-hostile, though.
- Officevibe offers single sign-on for free.

As a SaaS vendor, table-stakes cybersecurity functionality should not be an upsell opportunity. Your customers deserve to be empowered to follow best practices. It's also bad for you, as a vendor, to have your customers constantly suffering cybersecurity incidents due to your policies.

Cybersecurity is a big enough risk that I think all B2B SaaS companies should:

- Offer single sign-on on all plans.
- Support and enforce multi-factor authentication by default (if you support password-based authentication).
- At the very least, offer magic-link email-based authentication. This is a good option companies yet to achieve product-market fit, who can't justify the investment in more complex authentication flows.

Virtually any other approach is user-hostile and irresponsible. It also leaves opportunity on the table:

- Given the standard is to charge for single sign-on, it could give you a competitive advantage to offer it out-of-the-box.
- Centralised user management is a significant selling point for the Microsoft 365 ecosystem. If you compete with Microsoft and don't offer the best security standards, you give customers another reason to stick to the Microsoft ecosystem. Sometimes, to compete, you need to make some ecosystem concessions such as this.

In B2B SaaS, we often look to other B2B SaaS businesses to justify our practices (pricing, hiring, engineering, security). This helps best practices spread throughout the industry and is the basis for much of the content on this blog. But, sometimes, things catch on that don't make sense or are outright bad for users. Charging for single sign-on is one of those things, so I think it is time to buck this trend.

[^1]: Other single sign-on providers, like [Okta](https://www.okta.com), are also available.
[^2]: Slack does offer magic-link authentication, though.

Tags: advice, startups, technology

# Running an operations function within a startup

It is difficult for startup leaders to deliver major projects without neglecting their business-as-usual responsibilities. An operations team can solve this problem for startups by helping leaders with projects.

For example, a customer service team needs to keep on top of inbound support tickets and calls, which can be a demanding responsibility. Suppose you decide to move to a new help desk software. Someone must choose a new vendor, configure the new system, and roll it out to staff. In many startups, it is challenging for leaders to balance everyday responsibilities (support tickets and calls) with project delivery (new help desk software rollout), so one or more balls will be dropped.

A startup with a robust operations function won't have this problem. With the consultation of all relevant stakeholders, an operations manager can carry out the vendor selection and system configuration process. They can guide staff through the adoption of the new product. And most importantly, they can empower the customer service team to remain focused on servicing customers.

Conversely, an ineffective operations function can harm a startup. A startup can take the agency away from its teams by recruiting an operations team. Bad operations managers impose strict and ineffective ways of working on individuals who are perfectly capable of designing their own procedures. They disruptively roll out initiatives and fail to meet the needs of the teams they are meant to serve.

So, let's talk about the best ways to set an operations discipline up for success.

## Best practices for operations teams

An excellent operations team amplifies the capabilities of their colleagues. They collaborate with leaders and individuals to solve problems within the business through improvements to how everybody works and collaborates. 

Their goals include:

- Teams operate smoothly and effectively, taking cues from Agile best practices. Bottlenecks are mitigated, and teams can scale quickly with minimal disruption to the business.
- There is a culture of continuous improvement, where teams frequently improve and simplify their ways of working to meet the evolving needs of the business.
- Teams actively measure their performance. This data drive strategy and prioritisation.
- Cross-team collaboration and escalations are effective and harmonious.
- Outcomes are prioritised over outputs, and the scope is lean enough to deliver value without unnecessary effort.
- Teams are rallied behind a unified vision, and each member thoroughly understands the impact this vision has on the team, the business, customers and the wider industry.
- Ongoing agile rituals (*e.g.,* sprint planning, refinement, retrospectives) and ad-hoc collaborative workshops are well facilitated.
- Initiatives are adequately scrutinised and considered before they commence, and the appropriate documentation (*e.g.,* an initiative brief) has been completed.
- Upcoming work and progress on work are shared frequently and clearly with the broader organisation, particularly crucial stakeholders.
- Teams use fit-for-purpose, usable, capable, and cost-effective tools.
- Teams understand their capacity and, therefore, their future resourcing requirements in a quantitative way.
- Cybersecurity and the privacy of our customers, team, and partners are prioritised and managed effectively throughout the organisation.

They achieve these goals through two primary responsibilities:

- **Coach teams towards operational excellence.** Most of the time, the best way to help an organisation grow is to help others to achieve great things rather than to do the work for them.
	- Help leaders and members of teams to understand and communicate the problems they want to solve. This is typically done through an initiative brief.
	- Evangelise the principle of *outcomes over outputs* by helping leaders to not only select the right solutions but to explore multiple approaches before committing.
	- Foster a deep organisational understanding of SaaS, the SaaS business model, SaaS organisational norms, and the implications of this business model.
	- Coach leaders through change management by helping them to understand how their work may affect others and how they should communicate and collaborate.
	- Encourage teams to implement minimum-effective dose solutions that can later be improved through continuous improvement.
	- Help teams to prioritise their work so that they can focus on the most essential initiatives rather than be swamped by competing priorities.
	- Promote the spirit of *continuous improvement* by encouraging and facilitating post-mortems and retrospectives.
	- Encourage outcome-focused strategy planning by facilitating brainstorming and other strategy workshops.
	- Encourage collaboration over delegation. Ways of working packed with handovers between teams are inevitably full of bottlenecks. Stakeholders should collaborate towards a solution rather than delegate from silos or "throw over the fence".
	- Promote a culture of adaptability. Many individuals, teams and organisations are resistant to change. To succeed, we must embrace it.
	- Guide individuals and teams through complex change. This includes delivering training on new ways of working.
- **Lead and directly contribute towards operational initiatives.** Some initiatives are cross-department[^1] or especially complicated[^2] or important. These initiatives are often directly managed by our operations managers.
	- Lead internal projects to improve ways of working.
	- Act as the project manager for the initiatives that you own. Participate as a contributor to projects owned by other operations managers.
	- Be frugal and pragmatic. Simple solutions are usually better.
	- Manage operational risk with a bias towards simplicity, trust and empowerment. Just because something went wrong once doesn't mean we need a process. The risk of adverse outcomes must be weighed against the costs of excessive process requirements.
	- Document and regularly share learnings with the broader business.
	- Keep your initiatives well documented and well understood.
	- Empower others. You're here to drive transformation, not to be the sole proprietor of it. Even if you own an initiative, this doesn't always make you the best person to complete each task.
	- Work collaboratively with team leaders, allowing them to retain the autonomy of their areas of ownership.
	- Use data and industry benchmarks to inform effective decision-making.

[^1]: Imagine a startup that wants to move from tracking customer relationships in a knowledge base like Notion towards a CRM. This could impact how the finance team reports on sales results, how the sales team tracks opportunities, how the marketing team segments prospects for campaigns, and how customer service manages support tickets. Therefore, this initiative has many stakeholders, and it is not apparent who should own it primarily. Operations managers are great at bringing together multiple teams to get things like this done.
[^2]: Imagine a startup that wants to move towards a model where third parties can implement their product for new customers rather than their own internal teams. This might allow them to grow more quickly or expand into new markets. If they give this initiative to their already busy professional services team, it will move along very slowly. If an operations manager can own it and call upon the expertise of the professional services team only where necessary (*e.g.,* writing technical documentation), things will move faster.

Tags: advice, startups, operations

# How developer copilots, no-code, and app-generating LLMs might impact product development

Throughout the history of computer science, software development has become increasingly accessible. It is much easier to make complex software today than in 1980.

Abstraction is the primary mechanism by which software development has become easier. Abstraction is the process of simplifying complex systems by layering simpler systems on top. When you abstract away complexity, you make it easier to talk to your computer's hardware, but you reduce the specificity of what you can tell it.

For example, you can be extremely specific if you write instructions for your computer hardware using binary code. Binary code is a series of 1s and 0s directly representing instructions for the computer's processor. These instructions control the flow of electricity through the processor's circuits[^1]. So, you have a lot of control over what the computer will do, but you have a meager chance of understanding this binary code yourself. It is practically impossible to write complex software using this method because it is inconceivable to a human how the flow of electricity through a processor could amount to the rules and logic of a web application. So, on top of binary, computer science has begotten layer after layer of abstraction. 

In a scripting language like JavaScript, which lives many layers of abstraction above binary code, you have a plethora of tools available to you that make it very easy to write software. You don't need to tell the computer how to do arithmetic because JavaScript has built-in functions for that, amongst many others. The benefit of abstraction is that writing software is easier and quicker. The downside is that, with each abstraction layer, you lose some control over precisely what the computer is doing. Generally, this is unimportant, though it does have downsides. For example, it is easier to optimise software for high-performance and low-power consumption with lower-level languages (assuming you know what you are doing).

Another constant throughout the history of computer science is skepticism from engineers directed at new layers of abstraction. Suppose you are an expert with the popular programming technology of the day, and along comes a new technology, built on top, that is easier to learn and develop with, but less performant and more bug-ridden. There is a good chance you will be skeptical of this new technology, the developers who adopt it (especially those who have yet to learn how to write the more complex code you're proficient in), and the slow and buggy software built with it.

When JavaScript first gained traction as a language for developing software applications, it was met with significant skepticism from established programmers. JavaScript was never designed for this purpose, had legitimate, obvious, and serious flaws, and wasn't even that user-friendly[^2].

But it was also familiar to many people with little programming experience. Before JavaScript became a language for software creation, it was used by web designers and developers to lightly enhance websites. When it suddenly became possible to build complex software with JavaScript, many web designers and developers became software engineers. Like programming languages before it, JavaScript went from unserious and problematic to ubiquitous. Many more software exists today thanks to the ratification of JavaScript as a software development tool.

The thing about abstraction is, when you build software at one layer, the lower layers can improve without much (if any) need for you to change your software. So, the popularity of JavaScript led to improvements to the layers beneath it, which ironed out the creases. Additionally, things got better at the lowest layer: computer processors have become dramatically more efficient (in fact, some modern CPUs are now optimised for running JavaScript).

When a new layer of software development tooling is ratified, what happens to the developers proficient in lower-level languages? Many eventually adopt the new layer, while others continue to use their low-level languages for the purposes that remain viable. Not everything can or should be built using JavaScript or PHP, so low-level programmers who used to produce consumer software may instead work on other types of software like compilers or more performance-sensitive applications. Even when a low-level language dies in terms of new software projects, many engineers lucratively maintain legacy software that is still dependent on them.

I tell this story because the very same thing is happening today. First, with no-code and low-code tools, and now much more significantly with GitHub Copilot, ChatGPT, and the plethora of other LLM-backed development tools now emerging. The software development world is having the greatest existential crisis in its history. Will everyone be able to build software soon? Will software developers still have jobs?

Nobody knows how this technology will impact the industry or labour market. But, if history is anything to go by, I think software developers will survive the AI revolution, at least for the foreseeable future.

Many more people will be able to build high-level software in the very near future. At first, this software will suck, so many engineers will resist this new abstraction layer. But, soon, this software will get good and many engineers will move to this new way of working. They'll be way better at it than laypeople, so they might become 10x engineers. Like any technology, there is no finite amount of software that must be created before we're finished and can move on to something else. There will always be economic processes to digitise. The demand for software development is currently dramatically greater than the supply of software developers[^3].

Some engineers will stick or even move to lower-level programming languages and we'll be grateful because we will need their help to optimise the plumbing of these new abstractions. In fact, LLMs will likely lead to more rapid improvements to low-level technology. Just because new layers exist, does not mean development on old layers has ever wholly halted. Every layer needs maintenance and improvement, and LLMs will empower more engineers to dive deep to make these improvements. This technology will make every layer of the stack more accessible, which will ultimately lead to major changes at every layer. 

I expect that a dramatic improvement in the accessibility of software creation will lead to a considerable increase in the amount of bespoke software in the *technium*[^4]. Today, most businesses run on standardised software built by centralised product companies (*i.e.,* B2B SaaS companies). Even the most consolidated markets are highly fragmented, though (look at how many competitors Shopify has). This is because there is no one-size-fits-all way to digitise an entire industry. Soon, it will be much more affordable for a business to digitise on its own terms by building a considerable portion of its software stack. This bespoke approach to digitisation, which is a significant competitive advantage for large businesses like Amazon, will once again become a potential competitive advantage for mid-sized companies. Within enterprises, functions typically dependent on engineering teams for technological innovation will be liberated by the ability to build their own software: operations teams, customer service teams, sales teams, and more. SaaS companies might be disrupted more by their customers than by new SaaS companies.

Eventually, AI will be so good it can own the entirety of our digital world. I think it is safe to say that software engineers will no longer exist as a profession when this time comes. Creating software by hand will be more irrelevant than making horseshoes by hand today. When this time comes, we software engineers will have much bigger things to worry about — namely, the end of the world as we know it, for better or worse.

[^1]: [Learn more about binary](https://computer.howstuffworks.com/bytes1.htm).
[^2]: See: [a brief history of JavaScript](https://auth0.com/blog/a-brief-history-of-javascript/).
[^3]: **Will software engineers make less money?** On average, of course. But many of today's engineers will still have superpowers compared to laypeople adopting these new layers, so their skills will be more valuable than the mean.
[^4]: The *technium* is the human-made system of all technologies working together [as defined by Kevin Kelly](https://brandon.uno/links/531419637/).

Tags: advice, startups, ai, society

# Why your startup needs an operations team

A capable operations team helps startup leaders improve the business without neglecting their core responsibilities. This way, founders don't have to choose between improving their ways of working and their team's primary duties. This is a broad remit that varies by company but often includes some of the following goals:

- Drive improvements to how teams work.
	- Help the support team to find an efficient way to get through their customer service backlogs.
	- Guide product development through structuring new teams as they grow.
	- Assist sales with CRM adoption and utilisation.
- Vendor and supply chain management. Help the business choose which software tools to use. Manage procurement and logistics for hardware businesses.
- Risk, cybersecurity and compliance. Ensure the business operates responsibly in how it manages customer data, accesses software systems, and other compliances.
- Cross-team project management. Manage projects that require the input of multiple teams.
- People operations. Manage the employee lifecycle, from onboarding to off-boarding.
- Modelling and forecasting. Help teams to understand their future resourcing requirements.
- Goal setting and performance tracking. Help teams measure their performance and set goals.

Operations is a familiar role for businesses that interact with the real world. If your startup needs to hold inventory of a physical product, manage a logistics or a physical supply chain (hardware startups), manage a large workforce in the field (Uber, DoorDash), or utilise a network of physical locations (Airbnb, OpenTable), you probably already have operations managers. However, pure-play software-as-a-service companies increasingly employ operations managers too. Even some very early-stage startups embrace this trend, with some hiring operations managers before they hire product managers.

At first, the idea of a centralised operations team seemed like an anti-pattern. When you delegate responsibilities like Human Resources to a dedicated team, you take those responsibilities away from managers (at least partially). When you do this type of delegation, you make your leaders and managers worse because you give them an excuse to throw people-management problems over the fence to HR[^1]. I assumed this same principle should apply to operations — surely, strong managers should own the operating rhythm of their teams. Having led operations at startups for some time, I know that my instincts were wrong and that operations is a necessary function for most startups.

## The reality of startup leadership

All ambitious startups are resource-poor, given their goals. This means that startup leaders (people who own functions like customer service, customer success, sales, marketing, product management, and engineering) tend to be very busy people. The reality of most startups is that leaders struggle to keep up with their day-to-day responsibilities, let alone design and deliver major projects to advance the business.

For example, customer support teams in early-stage startups tend to need help with their business-as-usual responsibilities: answering the phone, responding to support tickets, troubleshooting complex issues, validate and escalating bug reports. When you ask them to roll out a new initiative on top of this, such as one to adopt live chat as an additional support channel, they may need help to take this on. They probably won't do enough research into the best ways to deliver this or the pitfalls to avoid. They may cut corners that will be detrimental to outcomes. They might move very slowly. And capacity isn't the only problem.

Many of the best startup leaders earned their experience in the trenches. This experience may equip them to tackle the business-as-usual responsibilities of their department but only sometimes gives them the meta-skills essential to identify and deliver operational improvements. This is another reality of early-stage startups: even experienced leaders who can run a function effectively may have knowledge gaps when it comes to project management and strategy.

For example, a customer success leader who has years of experience conducting the day-to-day tasks of their team might flounder when delivering projects. To deliver initiatives well, you need to know how to get to the heart of the problem, define a minimum-viable solution, coordinate with stakeholders, and manage rollout in a way that doesn't disrupt other teams. For many leaders without extensive project delivery experience, this can be a challenge.

## The role of operations management

It is possible for a centralised operations team to empower or oppress their colleagues. Their mandate must be to support the business, not to control it. It is easy for operations managers and big operations teams to try to control the strategy and culture of the company. 

An outstanding operations team amplifies the capabilities of their colleagues. They collaborate with leaders and individuals to solve problems within the business through improvements to how everybody works and collaborates. At their best, they:

- Support team leaders who can handle the business-as-usual needs of their role but don't have the capacity or capability to innovate 
- Lean into the leaders who most need help. Teams with more capacity or capability probably need less assistance, and team autonomy should be encouraged.
- Manage complex[^2] and cross-team[^3] initiatives. If something requires people from disparate teams to collaborate, operations managers are often best positioned to facilitate this.

A small, skilled, and effective operations team presents a startup with the opportunity to allow team leaders to focus on their business-as-usual responsibilities without the need to forgo business-changing improvements to how the business runs. Many founders struggle to choose between these step-change initiatives and the core responsibilities of their teams. With an operations function, you can have both.

[^1]: This is not an argument against having an HR team. HR is obviously critical. But to lead productively, managers need to retain a good amount of responsibility for people management.
[^2]: Imagine a startup that wants to move towards a model where third parties can implement their product for new customers rather than their own internal teams. This might allow them to grow more quickly or expand into new markets. If they give this initiative to their already busy professional services team, it will move along very slowly. If an operations manager can own it and call upon the expertise of the professional services team only where necessary (*, e.g.,* writing technical documentation), things will move faster.
[^3]: Imagine a startup that wants to move from tracking customer relationships in a knowledge base like Notion towards a CRM. This could impact how the finance team reports on sales results, how the sales team tracks opportunities, how the marketing team segments prospects for campaigns, and how customer service manages support tickets. Therefore, this initiative has many stakeholders, and it is not apparent who should own it primarily. Operations managers are great at bringing together multiple teams to get things like this done.

Tags: advice, startups, operations

# How accountability enables autonomy

Autonomy and accountability are intrinsically tied together. To achieve great results, people need control over what they do (autonomy) and they need to be motivated by real business outcomes (accountability). Effective delegation requires a balance of these two forces. When startup leaders fail, it's often the result of an imbalance between their autonomy and their accountability.  

Autonomy is your ability to determine the strategy for your area of ownership. You're autonomous if you can decide what you work on. If you simply execute someone else's plan, you have low autonomy.

Accountability is about ownership of outcomes. You're accountable if your professional performance is determined by the outcomes you deliver. If you are not held accountable for outcomes (because nobody is paying attention or because the buck stops with someone else), you are not accountable.

## Autonomy without accountability

It is common for an individual or team to be given autonomy but not accountability. They define their own strategy and ways of working, but they are not held accountable for the outcomes of their work. This situation often emerges when individuals are promoted to lead areas of the business where clear desired outcomes are not yet defined. 

Aspiring leaders often demand autonomy but fail to set targets and hold themselves accountable for outcomes. Individuals crave autonomy because control and leadership are fulfilling, and it sucks to have to implement someone else's vision, especially if you disagree with it. Conversely, individuals avoid accountability because it sucks to be seen as a failure when things go wrong (and it sucks to be demoted, fired, or miss your bonus). 

A party with strategic autonomy but no practical accountability will struggle to achieve tangible business outcomes. They care about business impact, but their judgement is clouded by what they find personally interesting or frustrating because they don't have specific outcomes in mind. This impacts their ability to prioritise work and choose practical solutions[^1].

For example:

- A sales leader with control over sales strategy and operations but who has little accountability to the business might spend more time on tools, processes, and networking when they need to get on the phone and make some sales.
- A product development team with strategic autonomy but no accountability to deliver business outcomes might spend more time on interesting and innovative technology that doesn't solve customer problems when they need to provide simple and practical solutions to meet specific customer needs.

In both situations, people keep busy and have the business's good in mind, but they fail to deliver outstanding results.

## Accountability without autonomy

It is also common for individuals or teams to be given accountability but not autonomy. They are held accountable for the outcomes of their work, but they don't have control over their strategy or ways of working. Usually, this is because someone is micromanaging the individual or team.

A party accountable for outcomes but with no say in strategy or ways of working is likely to fail. While it is conceivable that, with a perfect strategy dictated from above, a team or individual with little autonomy would succeed, it is unlikely because every good strategy requires feedback from the people who execute it. 

For example:

- **A salesperson who has been delegated a new market and is accountable for delivering ten new enterprise customers per month.** As this person makes sales calls, they will learn a lot about the quality of this strategy. They might discover that, in this new market, there are far fewer enterprise prospects, and it might make sense to pivot and target smaller businesses. 
- **A product development team accountable for delivering two new features every quarter.** As they build their chosen features for this quarter, they might realise the customer value delivered by one of these features is much lower than initially expected. Because they cannot influence their strategy, and their goal is to ship a fixed number of features rather than flexible and tangible outcomes, they will complete and release a feature that nobody wants.

Success will be unlikely in both situations if the people on the ground cannot influence the strategy.

## Balancing autonomy with accountability

Most people think that strategy is step one, and execution is step two. You create a plan, and then you execute that plan. But this unnecessary bifurcation of *the doing process* almost always leads to mediocre results. 

When you implement a strategy, you learn about its strengths and flaws. If you adjust your strategy based on these new learnings, you will achieve better outcomes than if you just stick to the original plan. The difference between a good and a great strategy is feedback from the people who execute it. No strategy is perfect, but iteration can get you close. 

A mediocre strategy supported by tight feedback loops can evolve into a great one. This is the crux of why autonomy and accountability are inextricably linked. Autonomy is decision-making. Accountability is how you measure the quality of decisions. If you have both, you can achieve remarkable outcomes. You will flounder with just one because the decision-making process lacks a feedback mechanism.

To be autonomous and effective, you also need accountability. To be accountable and effective, you also need to be autonomous. To achieve one, you need the other, so you must balance these forces.

## Advice for startup leaders

Both accountability and autonomy exist on a spectrum — neither is binary. To set up your people for success, you need to balance the accountability and autonomy you give them. 

A more autonomous team should also be more accountable. If your engineering team has a say in how they build features but not what features they build, they should be more accountable for the parts they have control over.

People should be held accountable for the layers where they make decisions. Suppose your engineering teams can choose what to build, but the leadership team dictates the high-level vision or direction for the year. In that case, you should hold the leadership team accountable for the vision and the engineering team for much of the rest.

If you want your team or employee to step up and take more control of their areas of ownership, you need to give them more accountability. Work with them to set some goals, so they know what outcomes they need to achieve. Let them rise to the occasion and determine the path (though this should always be a collaborative process).

If a team or employee struggles to achieve defined outcomes, see what you can learn from them about the strategy. They might have some interesting insights into why things aren't working out.

## Advice for ambitious individuals

Individuals and teams often ask for more autonomy but rarely for more accountability. To gain more control over the strategy, start by demonstrating accountability, which increases success chances and persuades leadership to delegate control.

When requesting more control from your manager, you ask for their trust in delivering desired outcomes. To establish this trust, prioritise accountability by collaborating with your manager to set target outcomes. Then discuss how these goals can be better achieved.

Rising stars within startups often achieve autonomy when things are going well. People who deliver a lot of value are given more responsibility and control. These same people are usually given accountability when things are going poorly. This can be a painful process. If you work with your manager to establish desired outcomes early, you can align your efforts with these outcomes.

[^1]: People naturally gravitate towards the problems and solutions they find interesting. By focusing on outcomes, teams challenge this instinct and can deliver better results.

Tags: advice, startups, operations, people

# Stay ambitious with the help of experimentation

As startups grow, they tend to be less ambitious in their product development efforts. This is because mature startups have a lot more to lose when things go wrong or when they waste time building features that don't turn out to be technically feasible or valuable to customers. I've heard from many CEOs frustrated with the attitude of caution that seemingly replaces the urgency of early-stage product development. Fortunately, it is possible to manage the *risk of being wrong* in a way that allows you to be more ambitious in your product development aspirations.

Even mature startups with large development teams are resource-poor. A startup with many development teams can juggle much more work than a lone technical co-founder at an early-stage startup, but there is still a limit. For example, a department with four teams can probably only deliver four initiatives at a time, so even mature startups must reject more product ideas than they accept. Teams need to prioritise. 

A consequence of this need to ruthlessly prioritise work is that the cost of a failed initiative is high. Initiatives fail when, after substantial development effort, teams discover insurmountable technical problems, or after it is delivered, they discover nobody wants it. If your team delivers only a few major features a year, it can be incredibly disappointing when one or more of those initiatives fail. When product managers and engineers experience failures like this, they prioritise initiatives that are less likely to fail because they'd rather deliver something that works than something that doesn't work. The problem with this approach is that when prioritising low-risk work, you deprioritise anything ambitious.

## Why ambitious change is required

Great startups change the world in their image. While iterative software development can compound into massive change and value creation over time, not all iterative improvements are equal. Just because a team consistently delivers new iterations doesn't mean those iterations add up to something massively valuable. Teams that iterate towards mediocrity may deliver much change, but not all change leads to positive outcomes.

When you have very few users, and limited confidence in the thesis behind your startup, there is an urgent need to build the product to find product-market fit. So, in the early days of startup building, the stakes of product development are existential. Ambitious change is required to overcome existential risk.

This existential risk does not go away for many startups when they achieve product-market fit. Startups must balance the need for mature software development practices with the reality that even early-stage companies are at risk of disruption. This is especially the case in immature fields where many startups aim to dominate through radically different approaches[^1]. A startup willing and able to tackle ambitious problems is well-positioned to win in a competitive and evolving market.

## Understand your assumptions

The plan for any project is full of assumptions, and all product development risks are assumptions yet to be tested. If you truly know something to be true, there is no risk in acting upon that knowledge. If you need to be right about something you're unsure about for an initiative to succeed, your chances of success are constrained. This is why the best way to de-risk ambitious initiatives is to separate high-risk assumptions from low-risk assumptions and validate the most important assumptions in advance.

When a team sets out to build a new feature, at a minimum, they make the following assumptions:

- This feature solves a problem, and therefore **customers will want it** (*i.e.,* this is a desirable problem to solve; this problem is worth solving).
- It is **possible to build this feature** and solve this problem (*i.e.,* it is feasible to solve this problem; our plan will work).

The more dubious the above assumptions are, the more risk there is in an initiative. I recommend that product leaders enumerate every assumption that makes them believe a solution is desirable and feasible.

Let's consider a team that wants to build a tool that can automatically order stock for retailers.

This team wants to build this feature because they assume that their customers waste a lot of time replenishing stock for their stores. Many teams don't find out whether customers want a feature until they release it — this is a costly way to test an assumption.

Regarding technical feasibility, this team makes several assumptions:

- It is possible to build a one-size-fits-all algorithm for stock replenishment.
- It is possible to programmatically place orders for new stock with wholesalers.
- Our product can access the data required to determine whether new stock should be ordered.

If some of these assumptions prove invalid, the project could fail. Many teams don't find out whether it is possible to solve a problem until part-way through the development process.

## Use experimentation to manage risk

It is wise for teams to test their assumptions before they commit to an initiative. If you can identify the assumptions important to your initiative, you can test them.

I recommend that teams score each of the assumptions undergirding their initiative on two dimensions:

- *What is the **chance** of being wrong?* How confident are you that you are right about this assumption?
- *What is the **cost** of being wrong?* What are the consequences of being wrong? Will the project fail if you are wrong about this assumption, or will you be able to find another way?

If you can score each assumption this way, you can easily identify which assumptions to test before starting an initiative. For each assumption:

- If you have low confidence, and the cost of being wrong is high, you should test this assumption before you start work on your initiative.
	- For example, if you have made a big assumption about technical feasibility that you have low confidence in, you should build a proof-of-concept of that component of your solution first[^2].
	- If you have made a big assumption about desirability, you can interview your customers to determine whether they care about the problem you want to solve[^3].
- If you are confident, but the cost being wrong is high, it might be worth further investigation.
- If you have low confidence, but the cost of being wrong is low, you probably don't need to worry about this assumption.
- If you are confident, and the cost of being wrong is low, you probably don't need to worry about this assumption.

![Focus your research and experimentation on high-risk items where the cost of being wrong is significant.](https://static.fastertimes.cloud/post-attachments/risk-matrix.svg)

Let's return to our team that wants to build a tool that automatically orders stock for retailers.

This team wants to build this feature because they assume that their customers waste a lot of time replenishing stock for their stores. The first thing they should do is talk to their customers to see if they care about this problem. If possible, it would be great to quantify the problem. For example, is it possible to measure how much time a retailer would save if this problem was automated away?

Regarding technical feasibility, this team makes a number of assumptions:

- It is possible to build a one-size-fits-all algorithm for stock replenishment.
	- This assumption can be tested with some experimentation. Task a developer to build a proof-of-concept algorithm for stock replenishment.
- It is possible to programmatically place orders for new stock with wholesalers.
	- This could also be tested through a proof-of-concept or some research into the various APIs that are available.
- Our product can access the data required to determine whether new stock should be ordered.
	- A developer could validate this assumption with some simple data analysis. How many customers have populated the data required to replenish stock?

Most teams find that most of the implementation work for an initiative is low-risk and that a large, ambitious, risky initiative can be validated through just a few small experiments.

[^1]: For a while, Sketch looked like it was going to be the company to finally disrupt Adobe. Then Figma launched and proved the superiority of multiplayer cloud-native solutions. Just because Sketch had achieved product-market fit, was still growing, and was not yet the incumbent, did not mean it was safe from disruption. 
[^2]: Many teams I have worked with the use [spikes](https://airfocus.com/glossary/what-is-spike-agile/) for these investigations.
[^3]: At one startup, we launched a brand and a website for a new product before we had built anything. We even ran a small marketing campaign to estimate how easy it would be to market this new product.

Tags: advice, startups, product, strategy

# Building teams is about strategically giving up control

In the early days of a startup, founders design, build, sell, and support their products. But, as a startup grows, founders increasingly solve problems through recruiting and delegation. Founders hire leaders and individual contributors to do a better job of owning the functions they once monopolised. If a startup is successful, this process loops indefinitely: things that founders owned become things that individuals own, which are then owned by teams, and eventually teams of teams. You could say that startup creation is a recursive process of strategically relinquishing control to others.

Sometimes, delegation leads to poorer results, and founders regret giving up certain areas of control[^1]. Other times, founders retain too much control over duties their team should own. While nobody can get this right every time, startup leaders can improve outcomes if they are strategic about delegation.

## Understanding your strengths

Every founder is capable in their own way, which means different founders need help in distinct areas. So, founders must understand their strengths and weaknesses to strategically expand their teams.

The most important responsibilities of a startup founder are to:

1. Recruit the right people to build your business[^2].
2. Build a great product.
3. Sell your product to your target market.
4. Retain customers.

Founders and CEOs don't need to personally execute these responsibilities. They just need to ensure they all get done. This is why recruiting is the most consequential responsibility of a founder: through recruiting, you can delegate the other burdens.

Some founders are great at sales and good enough at recruiting but need help with product, technology, and customer service. Other founders are strong with product and technology but need help with sales. Some successful founders focus exclusively on recruiting and team building. There is no ideal archetype. Founders should own the areas they are strong in and delegate everything else. As soon as you can afford to recruit someone better than you at any particular function, you should recruit them. For some founders, this means they divest from product strategy reasonably early in the lifecycle of their startup. For others, this means they retain ownership until IPO and beyond.

## The mechanics of delegation

The more vital a responsibility is, the more costly a flawed strategy and execution will be. Poor strategy and execution can result from delegating to the wrong people, delegating in the wrong way, or failing to delegate something you should.

This means that:

- Founders should be careful to delegate recruiting to anyone short of fantastic. After the first few hires, many founders consider recruiting a waste of time and leave it to their managers, HR team, or external agencies. But founders often make the best recruiters as they are most passionate about their market, problems, and solutions. If you build a mediocre team, you will create a mediocre startup. Most founders should be more careful when delegating this responsibility.
- Founder-market fit[^3] is a powerful force. Founders should never delegate product strategy to someone less compatible with the problem they need to solve. 
	- For many founders, their superpower is their experience with the problem because they've experienced it first-hand. These founders should own product strategy until they find someone better suited to the problem space. Someone who could've started the company themselves.
	- Founders with limited experience in their chosen problem space should hire a product leader with this experience. As crucial as founder-market fit is, some startups succeed without it. Industry experience is something you can hire for.
- It is safer to delegate customer service than to delegate sales. It is safer to delegate sales than to delegate product strategy.

Most importantly, founders need to be clear about how much they wish to delegate responsibility. If you only want to delegate execution and retain control of strategy, you need to be explicit about this in your recruiting strategy. They will likely fail if you recruit a leader but don't give them a good amount of autonomy.

For example, an early-stage founder who wants to own their sales strategy should not hire a VP of Sales. Instead, they should hire a salesperson to execute their strategy (and perhaps eventually a sales manager). An early-stage founder with a specific and inflexible product vision should hire product managers and technical leaders rather than a Chief Product Officer, who will expect to have control over product strategy.

## Dictatorships don't scale

It is impossible for a single person to effectively dictate a detailed product strategy to an organisation of many teams. This is because strategy and execution are not distinct phases in the product development process. As teams build software, they learn new details, and these learnings should impact strategy significantly. Therefore, a lot of product strategy happens during the execution process. In the early days of a startup, founders can be across the execution details of their product development teams. All successful organisations eventually outgrow this, though. 

When you have many teams working on many things, you need these teams to be accountable for good decision-making. The only way to make a team more accountable is to give them more autonomy. In this environment, product leaders (often the founders) may still make high-level product strategy decisions. However, these decisions should be increasingly informed and driven by the people close to the work and, most importantly, customers. In large teams, it is unlikely that the best ideas will come from the top, especially if leaders have consistently recruited great people.

## For how long should founders own product strategy?

A founder should own product strategy for as long as they believe they are the best person for the job. Founders with fantastic founder-market fit have a massive advantage over anyone they could hire into a product strategy role and should retain ownership for longer. Founders should only hire senior product leaders when they are ready to relinquish control (*i.e.,* trade *autonomy* for *accountability*). If a founder wants to own product for the long term, they should take it upon themselves to learn about the principles of good product management because this learning will help them to make good decisions and lead product teams. These founders should also hire an experienced product leader as a mentor and recruit experienced engineering leaders.

[^1]: [This tweet](https://archive.is/ByOJt) by Keith Pitt from BuildKite inspired this article.
[^2]: To hire, you need capital. So, *secure capital* is the most important responsibility of all.
[^3]: Founder-market fit refers to the degree to which a founder's background, expertise, and interests are well-suited to the industry and customer base they are trying to serve. A startup led by founders who are passionate about their target problem and market and with relevant experience and expertise is most likely to succeed. This is why early-stage investors bet on teams more often than specific ideas or solutions.

Tags: advice, startups, operations

# Finding the right software engineers for your startup

Engineers are the most important recruits for early-stage software startups, but many startups fumble their first engineering hires because they don't understand what type of engineer they need. Even a great engineer can fail at a company they're not suited to. Fortunately, there are a few general principles that startup leaders can employ.

## Look for experience

Early-stage startups do not have the foundations that make it easy to build great software. These foundations include comprehensive automated testing, reliable automated release pipelines, product management, and a user experience practice. Startup engineers need to be able to build quality software without these tools. Startups should hire engineers who are senior enough to solve problems independently in an unstructured environment with no technical foundations to fall back on. 

When you build towards product-market fit, you don't have time to lay perfect technological foundations. You don't have the best DevOps practices and move so fast that your code lacks documentation and comprehensive automated tests. Many startups are tempted to staff their early teams with junior developers to save money, but inexperienced developers usually struggle to build software effectively in this environment. In software development, the quality of your recruits is more critical than the quantity. Similarly, many engineers who only have experience in large corporations may have never built something significant from scratch and may face similar struggles[^1]. Engineering teams flounder when every new feature and technical improvement requires the leadership team's guidance. When you only have a handful of engineers, you need every engineer to own what they build independently. For that to be possible, you usually need experienced engineers[^2].

Startups often make the opposite mistake, too. They hire engineers at a point in their career where they want to be a manager, software architect, or some other leadership team member. These engineers sometimes see startups as a great place to get in on the ground level and quickly move into a management role[^3]. Sometimes, an engineer with a short timeline in mind for their move to management can struggle as an individual contributor, especially if they weren't one in their previous job. So, you need to hire an engineer who is experienced enough to build software independently without guidance but who is still committed to writing code every day and not seeking a management role in the short term[^4].

Developers at early-stage startups also need good product taste and an eye for usability. To build great software, your team needs to understand the difference between good, usable software and poor, unusable software. Until you have product managers and user experience designers, this will be more of an art than a science. So, your engineers should be people who appreciate effective software design.

## Comfort with the professional environment

In the early days, career development within a startup is unstructured and difficult to navigate. It is difficult for employees to clearly see the steps towards a promotion. It is also difficult for management to provide high-quality coaching, mentorship, training, and professional development[^5]. All early startup recruits should be comfortable with this reality. The flip side of the unstructured nature of career development within a startup is the opportunity to leap from an individual contributor role to an executive position eventually comes up for many employees. Startup life is high-stakes in many ways, especially in the early days.

Due to poor resourcing, startups require their team to fill many roles. Product managers might do sales calls, engineers might do some UX design, and salespeople might scope out features. For some, this is chaotic and unfair. For others, this is exhilarating and engaging and a fantastic way to learn about and try out other roles you may not have considered for yourself. 

## Technical experience

After you achieve product-market fit, the importance of software quality skyrockets. As you hire more engineers, developer/platform experience becomes crucial. This transition from moving fast at all costs to carefully balancing speed and quality (*i.e.,* startup to scale-up) is much easier if your engineers have experience with these mature software practices.

In the early days of product development, you are likely to cut more corners than you would like to admit. Eventually, though, you'll have to repay this technical debt. You will need to build infrastructure, testing, and deployment automation, a user interface style guide, stringent cybersecurity procedures, development environments, documentation, performance and cost optimisations, and more[^6]. This transition will be easier if you hire engineers with experience standing up these practices. Not only because they already know how to do it but because they know how to build software from day one that is easy to transition and mature. Most crucially, at least one of your early engineers should be an experienced stickler for cybersecurity.

## Hiring junior developers

Junior developers have a place in all startups, though I think your first few hires should lean more experienced. Junior developers tend to thrive in an environment where mentorship and solid developer tooling are available to them. Some startups get to this place very early in their lifecycle. Others do not. Suppose you hire very junior developers before the working environment of your startup is suitable. In that case, they will struggle to be productive and distract your more senior engineers from their efforts to build the product. 

Startups should hire exceptional junior developers when they come across them. Otherwise, they should stick to more senior developers until they have seasoned leaders on their team who have time to act as mentors and adequate developer tooling to empower juniors to contribute early in their tenure. At the same time, startups should strive to reach this point as early as possible because some of the best engineers you'll ever hire will be those you professionally developed internally. Less experienced software engineers are also sometimes the people most comfortable with the professional environment of a startup (young people can afford to take more risks in their careers).

[^1]: Just because you have relied upon or tweaked a continuous integration pipeline doesn't mean you know how to best set one up from scratch.
[^2]: It is common to come across individual engineers with very little experience who are perfectly capable of building great software on their own. The principle of hiring for the right level of expertise should not rule out *all* relatively inexperienced candidates.
[^3]: It is usually true that startups are a great place to move from an individual contributor role into a leadership position relatively quickly. But, in all roles from engineering to sales and product, recruits with leadership ambitions need to be prepared to contribute individually until the scale of the startup permits them to move into management.
[^4]: No engineer is too experienced to work as an engineer at an early-stage startup because not all experienced engineers want to be managers. Experienced engineers with no management ambitions can be the most valuable contributors to a team. Similarly, the best engineering managers are rarely the best developers. Different people are suited to each role, and it is unnecessary to think of engineering managers as *more experienced* or even senior engineers.
[^5]: It is the responsibility of startup leaders to provide the best support and professional development to their teams. This benefits not only employees but the startup and the leaders themselves. However, it is unrealistic to expect any of this to be perfect in the early days of development.
[^6]: While startups can and should strive to build these foundations as early as possible, it is unrealistic to expect perfection in all of these areas. If you gold-plate everything you create in the early days, before you even know what your product should be, you will inevitably waste time building tooling for things you will soon throw away as you pivot towards product-market fit.

Tags: advice, startups, people

# Employer brand for startups

Recruiting is often the biggest challenge for early-stage startups. When your product is unproven, your credibility as a founder is yet to be established, and you compete with established employers, it can be difficult to convince anyone to join your venture. Corporate tech companies have bigger budgets, generous perks, and great brand recognition. But startup building is all about punching above your weight. Recruiting gets easier as a startup grows and establishes itself as a desirable brand to work for. It is possible to accelerate this process with intentional employer brand design.

## Understanding employer brand

Startups with a strong employer brand find it much easier to recruit new staff. Instead of paying recruiters for expensive outreach-driven recruiting, candidates come to them. They don't need to work as hard to sell the dream to prospective employees. They attract the highest-quality talent in the market.

A brand can mean different things to different audiences. Your value proposition for customers differs from your value proposition for employees or partners. Still, all the principles of good branding apply to employer brands. Like product brands, employer brands consist of two core elements:

- Positioning is what you bring to the table, who you target, and how you're different to the competition.
- Awareness is the reach of your brand. Essentially, how famous are you?

A well-positioned brand that nobody knows about is worthless. A famous but poorly-positioned brand is a public relations disaster. Both of these areas need investment.

## Employer brand positioning

How you position yourself in the talent market will greatly impact your ability to recruit. Startups lean more heavily on employer brand positioning than awareness because fame is difficult for fledgling, unproven companies.

When corporate technology companies position themselves as employers, they prioritise the following value propositions:

- Generous compensation, including both salary and stock options.
- Structured career development.
- Perks like a personal office budget, office amenities, company retreats, and free lunches.
- The status that comes with working for a well-known brand.

Most startups copy these value propositions to establish themselves as desirable employers. While this works for some generously-funded ventures, most startups cannot compete with established technology companies on any of these dimensions. This is why startups should instead take a completely different approach.

Corporate technology companies are safe, slow, and well-compensated places to work. Startups are risky, fast, stressful, and resource-poor. When a startup adopts the corporate tech talent playbook, they not only fail but also attract the wrong type of talent. The kind of person who desires an easy, well-compensated cruise through corporate tech life is likely to fail at a startup. Startups that act like corporate tech companies will attract people who want to work for corporate tech companies. This is not to say that people with corporate tech experience can't succeed in startups — the same employee can have very different needs at various career stages. 

Instead, startups should differentiate themselves from their competition in the talent market. While every startup needs a different employer brand, some of the dimensions to consider are:

- Mission alignment. Every startup needs a mission. By defining your company culture and brand around this mission, you will attract people with the same values. If your goal is to topple Intuit's dominance of the tax industry, you need to recruit people who want to change the world in this way.
- Challenge/opportunity alignment and risk tolerance. Nobody should rest and vest at a startup. If you are clear with prospects that yours is a company where people will work hard to achieve something big (or fail miserably), you will attract people willing to work hard for the slim chance of a major payoff in the increased value of their shares. Most people don't want a job like that, and that's OK.
- Opportunity for rapid learning through unstructured career development. Startups don't offer structured career paths where the average employee can slowly climb the corporate ladder. Rather, they offer an environment where the best people can move from entry-level support to hands-on leadership positions within a year. People wear many hats and become versatile generalists at startups. They learn how to found their own company.
- Community. While any organisation can contain great communities, no corporation can compete with the sense of purpose, belonging, and camaraderie that even dysfunctional startups often achieve.
- Impact. An employee can individually impact a small organisation much more than a large one. Every early-stage startup employee should feel like an entrepreneur.

Great brands are defined not only by what they are but what they are not. To create a great brand, lean into the strengths of your startup. But, more importantly, don't try to pretend you are something you're not.

## Employer brand awareness

While some startups achieve fame very quickly, most cannot compete with established tech brands for attention. Fortunately, positioning is much more important than fame. For every founder who is laser-focused on startup building, there are many more who spend their time building fame on LinkedIn or Twitter. Fame is worthless when you have nothing to sell.

For many startups, the best way to build employer brand awareness is the same as the best way to build product brand awareness: starting with a niche. By focusing on a niche, it is easier to attract the attention of the most important part of your overall audience. From there, you can expand into other niches, and before you know it, you'll have broad brand awareness.

- It takes a long time to pay off, but all startups should build a community around their product. Your startup is built around your vision for the future. You need to assemble your fellow radicals. As a community forms around your startup, opportunities for growth, partnerships, and recruiting will emerge naturally.
- As an employer, you should align yourself with a technology community. Become the biggest supporter of the Tasmanian Rust ecosystem. Host the meetups. Support open-source projects. Always choose technologies that are growing in popularity. The more fanatical the existing community seems, the better.
- Join and build communities centred around the audience for your product. If you sell software to hospitality companies, you should become a cornerstone of that community. You might not get as many great engineering recruits through these communities, but you'll find some of your best account managers and salespeople.

As a resource-poor startup, your best bet is to be physically present. The room needs to be small enough that you can stand out but big enough that it adds a valuable cohort to your audience. It's hard to be the most attractive place in the world for JavaScript developers to work. It's much easier to be the best place for Next.JS developers in Chicago.

Tags: advice, startups, people

# Cybersecurity for startups

Startups can be flippant with cybersecurity, but even small companies are targets for attack. Worse, many startups never outgrow their poor security habits. For every high-profile breach, many early-stage startups face existential risk due to poor security posture.

Fortunately, healthy security practices are easy to achieve when you have them in mind from early in the lifecycle of your startup. A single article can't comprehensively cover everything a startup should do, but this is a good start for anyone yet to take security seriously.

## Access management

Startups use a lot of SaaS products to get their work done. When a startup is breached, it is usually because someone on the outside has managed to access an employee account for an important SaaS tool. By managing access responsibly, you can mitigate this risk.

First, create and maintain a list of all company-provided software tools. This list will help you to periodically audit access and billing and guide your employee on/off-boarding procedures. 

Second, ensure authentication for each tool is managed in the most secure way possible:

- **Centralise access management** so that a small group of trusted individuals are responsible for granting and revoking access to systems. Many startups give this to their finance, HR, or operations teams. 
	- Employees should only receive the access [they require for their job](https://en.wikipedia.org/wiki/Principle_of_least_privilege) — don't give all employees access to all systems, and don't make everyone an admin. 
- Where ever possible, **utilise single sign-on**, which allows you to access an application using the credentials of another. Microsoft and Google both offer SSO solutions that enable your employees to use their Microsoft or Google accounts to access other SaaS tools like Atlassian or Slack.
	- By centralising access to a single Microsoft or Google account per employee, you make it easier to grant and revoke access to your employees. By disabling a user's Microsoft or Google account, you also disable their access to other connected systems.
	- Another benefit of this centralisation is that it reduces the number of passwords each employee needs to manage. The fewer passwords an employee has to manage, the easier it is for them to do so responsibly.
- Adopt a company-wide **password manager**, like 1Password. Password managers are the most secure place to keep secrets. Their features also make it easier for your staff to manage access responsibly, which increases the probability they'll do so. 
	- Responsible use of a password manager should be mandatory for all staff. Make sure they keep passwords in the company-provided password manager and not their web browser's default keychain.
- Where single sign-on is not supported, **enforce multi-factor authentication**. Many SaaS apps allow you to force all users to have MFA enabled. One-time passwords, securely stored in your company-wide password manager, are usually the best available type of MFA ([WebAuthn is coming](https://webauthn.guide/)). SMS should be used only when it is the only option on offer, as SMS is relatively insecure.
	- MFA is most crucial for company email accounts. If someone can get into your employee's email account, they can send seemingly legitimate emails on their behalf. They can also likely reset and access many other accounts.
- Avoid company-wide shared accounts. It might save you some money to share SaaS accounts, but it could be an expensive mistake if access is compromised. Use common sense based on the type of data being stored in each system.
- Replace any vendors who do not support SSO or MFA via a password manager. When no alternative is available, submit feedback to these vendors.
- As a software vendor, offer SSO and MFA to your customers. It is much easier to offer these from the start than to add them later. 

## Prepare for phishing

Phishing is one of the most common ways that startups are breached or scammed. No business is too small to be the target of a phishing scam. Almost every startup I have worked with has had phishing attempts against them.

> *Phishing is a method of identity theft that relies on individuals unwittingly volunteering personal details or information that can then be used for nefarious purposes. It is often carried out through the creation of a fraudulent website, email, or text appearing to represent a legitimate firm.*
> — [Investopedia](https://www.investopedia.com/terms/p/phishing.asp)

Phishing is relevant to SaaS startups because:

- Scammers are likely, at some point, to contact your customers, pretending to be you, to try to get access to their accounts or to get money out of them.
- Scammers are likely to contact your staff, pretending to be senior management, one of your customers, or one of your vendors, to try to get access to their accounts or get money out of them.

Common phishing/spoofing scams include:

- A scammer sends your customers a fraudulent log-in page, impersonating your SaaS, to try to collect their username and password.
- A scammer sends your staff a fraudulent log-in page for one of the systems you use to try to collect their log-in details.
- A scammer contacts your customers, asking them to update their payment details on a fraudulent payments page.

Some ways to reduce the likelihood of being phished include:

- Avoid using email wherever possible. Have your customers contact you via your app or support hub and manage their payments from within your app. Post any company-wide announcements (such as the rollout of a new internal system) to your company knowledge base (*e.g.,* Notion, SharePoint, Confluence) and communicate over Slack, where sender identity is easier to verify. Only email things that you're comfortable with leaking out.
- You should obviously be using SSL (*i.e.,* HTTPS) for all of your web apps/endpoints.
- Ensure all staff use SSO or MFA when accessing internal systems. Offer SSO and MFA to your customers so that even if a scammer is able to get their username and password, they still cannot access your software on their behalf.
- Utilise [DMARC, DKIM, and SPF](https://www.cloudflare.com/en-au/learning/email-security/dmarc-dkim-spf/) to secure your company emails. These simple technologies are easy to set up and will make it much harder for third parties to impersonate you.
- Establish a process to verify your customers' identity when they contact you, especially when they are asking you to make a change on their behalf.
	- It can also be a good idea to have your customers nominate a restricted list of users who can request this type of support. This can be automated within the UI of your app.
- Educate your employees. For such a common scam, employees may know little about the risks of being phished. It is your responsibility as an employer to provide training to new employees. Consider baking this into your employee onboarding process.

## Establish a data-management policy

Leaky file storage and data loss can be major risks for startups. **Establish a standardised policy for how data, documents, and files should be managed**:

- Decide between the Microsoft and Google office suites and ensure employees only use the chosen suite. If you choose Microsoft, employees shouldn't be using their personal Google account for the sake of Google Sheets.
- Documents should only ever be stored on Google Drive or Microsoft OneDrive. This dramatically reduces the risk of data loss in the event that an employee's device is lost or damaged. It also makes it easy for you to revoke access for compromised devices or former employees. Employees shouldn't keep local duplicates of files.
- Adopt a company-wide wiki tool like Notion, Coda, or Confluence. By default, all documents should be created within this wiki. Only use another tool when specialised functionality is required (*e.g.,* Excel or Sheets for financial models, Word or Docs for contracts).
- Customer data should only live within your CRM (*e.g.,* HubSpot or Salesforce), billing system, or ERP. Where possible, conduct any reporting directly in those systems. When you need to export data for analysis in a spreadsheet, anonymise it. At the very least, keep exports confined to a secured directory and delete them when they are no longer needed (many finance teams do this).
- Data in analytics and business intelligence systems [should be anonymised](https://www.imperva.com/learn/data-security/anonymization/).

## Centralise and log sensitive requests

Some business operations are more sensitive than others. Delegate these tasks to a specialised team of individuals (this could be your HR, finance, or operations team), and log requests and actions.

Examples of this type of work include employee on/off-boarding tasks, granting an employee access to a new system, adjusting terms and conditions, and installing a new Slack app.

The easiest way to do this is to funnel these requests through a standardised request form that creates work in your support help desk, CRM, ERP, or task management system like Jira.

## Avoid sensitive data

The best way to secure sensitive data is to delete it or never have access to it in the first place. Only collect and keep what is necessary to provide services to your customers.

- Never store credit cards. [Tokenise them in your payment gateway](https://stripe.com/docs/api/tokens) or in a specialised tokenisation service.
- Anonymise data in product and platform analytics. If you need to know who did what, use a unique cryptic identifier for each customer so that you can identify customers internally without adding PII to your analytics.
- Limit what your staff can see in any admin panels or internal tools. [Don't give everyone access to God Mode](https://decrypt.co/36912/twitter-god-mode-panel-used-to-spy-on-beyonce-before-bitcoin-hack).

## Responsible product development

As a software vendor, you have the same responsibilities as your own vendors. Offer SSO and MFA to your customers. It is much easier to offer these from the start than to add them later.

Architect your product with security and privacy in mind. Consider quarantining services that handle sensitive data from other services so that as few people as possible can access them. Encrypt sensitive data in transit and at rest. Collect service logs, so you know who is accessing what. Don't keep secrets (API keys) in code repositories. Sanitise inputs to mitigate code and SQL injection.

[Audit your dependencies](https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-supply-chain-security) and keep them up to date. [Subscribe to publicly disclosed cybersecurity vulnerabilities](https://cve.mitre.org/cve/) to be notified when new vulnerabilities are disclosed. 

Unless you can properly enforce it, avoid charging customers per user. This encourages them to share accounts internally. Try to charge based on the value you provide instead. Similarly, many SaaS companies charge a premium for SSO — you should avoid this, if possible, as it is always in your best interest to provide the best security to your users.

Seek external advice. As you grow, the potential damage of a breach grows exponentially. So, your security practices should improve beyond the simple baseline outlined in this article. Most governments have cybersecurity recommendations for small businesses that you should be across. [Data residency](https://en.wikipedia.org/wiki/Data_localization), for example, is regulated in many geographies and industries. [OWASP](https://owasp.org/www-project-top-ten/) is a great resource for engineers. If, as a technical founder, you don't have experience with securing a SaaS product, ensure one of your early hires has done this before.

Tags: advice, startups, operations, technology

# Great pricing models make prioritisation easy

When a startup and its customers have the same goals, product development and sales teams can become singularly focused on delivering value to customers. Great pricing models enable this alignment of goals.

Products should be priced based on the value they deliver to customers. Value-based pricing ensures that a startup will make more money when it delivers more value. Therefore, a startup is incentivised to constantly strive to deliver more value to customers. Most business-to-business software products deliver value to customers by increasing revenue or reducing operating costs for their customers. These startups should charge based on the revenue and cost savings they deliver.

For example, a point-of-sale solution for hospitality businesses captures payments to deliver revenue. It can also streamline the customer service experience to reduce operating costs, leading to additional revenue because it enables more customers to be served.

Value-based pricing for this point-of-sale product would align software fees with the amount of revenue and cost savings delivered by the product. This aligns your startup's goals with your customers' goals: product development efforts that increase customer revenue will automatically increase the revenue for your startup. The same goes for reducing operating costs.

Prioritisation is an unwinnable game when the initiatives that will best benefit your customers differ from those that will best benefit your startup. If you build what customers want without delivering positive outcomes for your own business, your business is at risk. If you build exclusively to benefit your startup, you may achieve results in the short term, but eventually, customers will lose faith in you and leave. Bad pricing models are often the cause of this incongruence.

For example, a startup that charges customers for individual features is incentivised to build and sell features. On the surface, this looks like aligned incentives. Customers want features. By building and selling new features, startups can make more money. Everybody wins, right? Unfortunately, this view is detached from reality.

Product development teams that constantly build new features and products end up with broad, feature-rich, but mediocre and difficult-to-maintain products. Furthermore, additional features aren't always what customers need (even if they tell you otherwise). Similarly, sales teams that can only deliver by selling more features to each customer inevitably end up selling unneeded features. This isn't good for customers.

The goal should be to deliver value by solving real problems. New features might be nice, and they might even be delightful, but they aren't guaranteed to deliver outcomes to the businesses a startup supports.

## How to price your product

Most B2B software products deliver value to customers by increasing revenue or reducing operating costs for their customers. Some do both. The best way to price your product is to first quantify the impact it has on these outcomes and then capture some of the value you are creating by pricing accordingly.

If your product primarily generates revenue for its users, it is critical to measure and attribute this revenue. Metrics like conversion rates play into this measurement. By measuring the revenue you are bringing in for your customers, you can authoritatively justify the value you are creating for them. This allows you to align pricing with value (you could charge a percentage of revenue you generate). It also makes it easier to sell your product by using real metrics and case studies within your sales conversations. 

It is more challenging to measure your impact on operating costs. One way is to estimate the number of hours saved. This can be done through information gathering during the sales process (ask your customers how much time they are spending on relevant tasks) and try to measure these same numbers within your product. Compare before-and-after results to calculate savings. Another way is through productivity metrics, like how many operations a user can complete over a given time period. For example, an email help desk software might measure how many support cases are completed each day. Over time, they should aim to improve the productivity of support teams and measure the impact their product development efforts have on these productivity numbers. Savings should be articulated in hours saved. You can also estimate actual cost savings by considering the cost of the hours you are saving (i.e., look at the salaries of the people you are making more productive).

For something that startups pay little attention to, pricing greatly impacts business outcomes like growth, revenue, profitability, and viability. Second-order consequences like incentives are just as important. Companies that have failed to align their interests with the interests of their customers struggle to deliver value while improving their business. Startups with fantastic goal alignment with their customers find it comparatively easy to prioritise work.

Tags: advice, startups, strategy

# How to sell your SaaS product

When you build a company, you need to build a repeatable and sustainable sales model:

- **A repeatable sales model is one where you can win new deals by repeating the same steps.** Steps include the activities that attract new leads, how you structure your conversations with opportunities, how you qualify them, and how you close them. This repeatability makes it easy to scale your sales function and forecast the growth of your product. If you recruit every new customer in a unique way, your sales model is not repeatable, and growth will be slow and painful.
- **A sustainable sales model delivers new customers profitably.** Your startup may not be profitable, but your sales model needs to be. A sales model is sustainable when you earn more money from each new customer than you invested in recruiting them. The more profitably you can grow, the faster you can grow because you can invest that profit in new sales. 

The most important factor determining which sales strategies will work for your startup is your pricing, which should be determined by the value you bring to the market and the willingness of your market to pay. Because the goal is to grow sustainably (*i.e.,* profitably), companies that earn a lot of money from each customer can afford to spend a lot to acquire each customer. Similarly, companies with cheaper products have smaller customer acquisition budgets per customer. Some marketing and sales opportunities cost more than others, so different activities are most appropriate for differently priced products.

Expensive products are generally best sold through a hands-on sales process. These products are expensive because they solve a critical problem for large businesses. Because these businesses are large, and the problem is significant, a hands-on sales process is often required to understand the needs of each prospect, outline any required configurations or customisations, and convince the prospect that the solution, and the startup behind it, can be trusted. Because this highly-engaged way of selling is expensive, startups need a highly-targeted top-of-funnel strategy. When your cost to sell is high, spending time handling leads that are a poor fit for your product is an expensive waste. A targeted top-of-funnels strategy filters out most low-quality leads, leaving your sales team with quality opportunities to process.

So, if your product is expensive:

- A hands-on sales process is required to convince prospects to trust your product and team. This is an expensive way of selling, but you can afford it thanks to your high price point.
- An expensive sales process requires a targeted top-of-funnel strategy because it is expensive for your sales team to manually disqualify leads.

Top of funnel (*i.e.,* marketing) activities that are most likely to work include:

- Outbound sales and account-based marketing.
- [Channel/partner sales](https://fastertim.es/post/getting-started-with-partnerships).
- Targeted digital advertising.
- Attending and hosting events.
- Webinars.
- Community building.

In contrast, you need a hands-off sales strategy to grow cheaply-priced products. Because each new customer only contributes a very small amount of revenue to your business, you cannot afford to engage with each customer individually. Instead, the sales and onboarding experience must be completely automated and self-service. The best way to grow a low-price product is through viral growth. Viral growth is a sales model where existing customers sell your product for you. Network effects are the classic example of this — your product is more valuable to existing customers if they bring additional customers on board. Twitter, for example, is more fun if your friends use it. Companies like Twitter need to do everything they can to encourage their users to invite their friends and colleagues to the product.

So, if your product is cheaply-priced:

- You can only afford a hands-off sales model. Achieve success through a [self-service onboarding experience](https://fastertim.es/post/should-saas-products-offer-free-trials) and an effective top-of-funnel strategy.
- Because you require many customers to achieve profitable growth, you must cast a wide net. Your product and top-of-funnel strategy need to target a broad market.
- Expensive top-of-funnel tactics, like outbound sales and account-based marketing, are unlikely to work sustainably.

Top of funnel (*i.e.,* marketing) activities that are most likely to work include:

- Viral growth/network effects (including affiliate marketing).
- Brand advertising (digital, podcasts, influencer, and even legacy channels like print, direct mail, TV, and sponsorships for mass-appeal products).
- Webinars.
- Community building and events at scale.
- [Channel/partner sales](https://fastertim.es/post/getting-started-with-partnerships).
- Content marketing (and organic/SEO).

## Profiling your startup

Whether your startup fits into the high or low-price category may not be obvious. This is because many B2B SaaS products sit somewhere in the middle. For example, many products are valuable (and therefore expensive) enough to justify a hands-on sales model but cannot make outbound sales work sustainably. Similarly, some startups are affordable to the point where they need to be self-service and focus on top-of-funnel marketing but have little opportunity for virality. 

The solution here is to pick a starting point and experiment from there. First, decide whether a hands-on or hands-off sales model will work best. Second, experiment with how you structure those conversations and the various top-of-funnel tactics that may fit well with your sales model. 

To determine if your sales model is working, calculate your *CAC Payback Period*. *CAC Payback Period* estimates the number of months it takes to recoup the cost of acquiring each customer. How long does it take for your customers to pay you as much as you spent acquiring them? Calculate this by comparing your CAC (*Cost to Acquire a Customer*) to your ARPA (*Average Revenue per Account*) while factoring in your *Recurring Revenue Gross Margin*:

```
CAC ÷ (Average Annual Recurring Revenue × ARR Gross Margin) × 12
```

Most SaaS companies should target a CAC Payback Period of twelve months or less (though this can vary for startups with very high or very low customer churn). If you are overperforming in this metric and struggling to close deals, you probably need to be more hands-on in your sales process. If you are underperforming, you are being too hands-on and might need to increase your prices, find a way for your salespeople to close more deals each, or move to lower-cost top-of-funnel activities.

[Experimenting with sales is a critical part of the journey towards product-market fit](https://fastertim.es/post/sales-product-market-fit). You will likely try many ways to attract leads and close deals before you land on a repeatable and sustainable model.

## Segmentation drives success

Many products can satisfy customers of different sizes. This is especially true for [mature products that have gradually targeted larger customers](https://fastertim.es/post/why-its-so-hard-to-move-down-market). Segmentation is the best way for these startups to succeed:

- Segment your customers and prospects into cohorts based on the revenue you earn from them. 
- Those who contribute a small amount of revenue each year should be targeted differently to those who come on board and immediately contribute a lot of revenue.
- By marketing and selling to these customers differently, you can optimise your sales model for each cohort of customers. How you sell to very large customers should be different from how you sell to mid-sized customers, which should be different from how you sell to very small customers.

Some startups target multiple user personas. For example, two-sided marketplaces like AfterPay, eBay, and Amazon must attract sellers and shoppers. These companies succeed because they segment their customer acquisition strategy:

- Each shopper only contributes a small amount of revenue, so they should acquire shoppers through a one-to-many, low-cost acquisition strategy. Viral growth is ideal for this user profile.
- Each merchant contributes significant revenue, so they should acquire merchants through more hands-on sales strategies.

In general, segmentation is the best way to scale a sales team. Even if you only target customers of a specific size, you should still segment your prospects by other factors (like region and industry vertical) as you grow. More segmentation enables more focus and standardised ways of working, leading to a more repeatable and sustainable sales model.

## Product-led growth

Product-led growth is a business strategy focusing on using the product to drive customer acquisition, engagement, and retention. This approach prioritises building a product that is so valuable and easy to use that it generates word-of-mouth marketing and viral adoption rather than relying on traditional sales and marketing tactics. Product-led growth aims to create a self-sustaining growth cycle where the product generates its own demand. It is often paired with a freemium pricing model.

Product-led growth is, of course, a great strategy for low-price products. But, it has also helped some expensive products reach a massive scale. Usually, these startups have succeeded by onboarding individual users onto free (or cheap) plans and later upselling their organisation. For example, a small team can sign up for and use Slack, Jira, or Zoom for free. But, as the product becomes more popular within an organisation, power user features become more valuable and important. This is when the sales team targets existing customers.

Product-led growth is fantastic for products that:

- Target both small and large businesses.
- Have a large total-addressable market (not too niche).
- Can satisfy individual users on their own (if the entire organisation needs to adopt your product for it to be useful, there is little point in employing a product-led growth model).
- Can be self-service (your cost to service a customer must be low for your smaller/fremium users).

While product-led growth is now widely considered the best way to grow a SaaS startup, it is not appropriate for all products. [It also doesn't necessarily lead to greater profits](https://tomtunguz.com/plg-less-profitable/) because a sales team is still required to convert those big deals. If your startup only targets large businesses, cannot satisfy individual users on their own or requires a lot of configuration during the onboarding phase, product-led growth probably won't work for you.

Tags: advice, startups, highlights, sales

# How to capture value in the AI gold rush

Startup leaders want to integrate AI into their products. Prospective founders want to build businesses on top of AI. Investors wish to generate alpha. But, it's unclear who is best positioned to capture value as Large Language Models enter the market.

After reviewing Peter Thiel's *Characteristics of a Monopoly* (from [Zero to One](https://www.amazon.com.au/dp/0804139296?tag=zto-20&geniuslink=true)) and Clayton Christensen's [The Innovator's Dilemma](http://claytonchristensen.com/books/the-innovators-dilemma/), I believe the most valuable AI companies will be:

- Those who build and own differentiated and proprietary models.
- Those with exclusive access to large, valuable, and specialised datasets.
- Big Tech and scaled SaaS companies who integrate AI into their existing products (and absorb the additional costs that come with AI).
- Startups that solve previously unsolvable or expensive to solve problems and prioritise user experience.
- Startups that embrace on-device AI models to disrupt incumbents with a dramatically cheaper solution.

Many of today's AI startups either focus on building differentiated and proprietary models or using out-of-the-box models to build SaaS products. Those using out-of-the-box models are failing to differentiate through technology, which will result in a mediocre and commoditised market. This same pressure may even push the creators of proprietary models, currently focused on providing services to startups, to eventually productise this technology themselves, offering solutions directly to businesses and consumers.

## 1. Proprietary technology

**Technology is the best way to achieve and maintain leadership in a market.** A product is best positioned to win if it can solve practical problems that other products cannot. Even with competitors, if your technology allows you to offer a dramatically better or cheaper solution, you have the best chance of dominating your market.

The most advantageous way to differentiate your technology as an AI startup is to create your own proprietary models. A startup with exclusive access to the best model for its use case has a fantastic technical moat. Unfortunately, this is the most expensive and high-risk way to build an AI startup. The expertise and resources required to create your own model are costly, and there is no guarantee your model will be better than an out-of-the-box solution.

This is why many AI startups outsource the most complex layers of their technology stack to third-party technology that is easy for others to access. They utilise APIs like OpenAI or open source projects like Stable Diffusion. This is an easy way to build an acceptable solution, but drawbacks exist. Notably, technology differentiation is difficult when your competitors have open access to your most important technology.

Another way to differentiate your technology is by augmenting the technology you are outsourcing. Many startups have used tactics like reinforcement learning to layer additional intelligence on top of out-of-the-box AI models. GitHub Co-pilot, for example, uses a GPT language model reinforced with code generation in mind. The downside of this approach is that you may have to reimplement your augmentations with each new model generation (like the upcoming GPT-4). Additionally, skeptics believe that GPT-4 without augmentations will likely outperform GPT-3 with augmentations, decimating any technology moats that depend on tactics like reinforcement learning. Organisations with exclusive access to large and valuable specialised datasets are best positioned to augment existing models. These organisations are able to train models in a differentiated way because their competitors cannot access the data they use for training (most models are trained on the public web, so it is reasonable to expect the quality of these models to eventually converge).

However, it is possible to build a technological moat for an AI company without the differentiated technology being the AI model itself. User experience may be the best pathway towards technical differentiation for many AI startups. One thing that is apparent when using generative AI is that experienced DALL-E or ChatGPT users can get much better results than inexperienced users. This is because the quality of the output depends on the quality of the prompts used. This gap in the outcome quality is an opportunity for user experience design to define market leaders. This has been the case in software-as-a-service for a long time. As cloud computing and web standards have improved over the past decade, technological moats in SaaS have diminished. As a result, many of the biggest winners through the history of software-as-a-service are less-capable products with better product onboarding and self-serviceability. The same will likely apply to B2B AI startups.

## 2. Economies of scale

Cost is the most significant factor for whether a new technology will help or disrupt currently dominant businesses.

New technologies that are dramatically cheaper than current solutions are best deployed by startups. These technologies tend to be worse than what exists but can satisfy niche customers because they are cheap, fast, and good enough. However, the technology improves and eventually becomes good enough for big customers. This is when startups begin to disrupt the dinosaurs in their industry.

Expensive new technologies are best deployed by incumbents who have achieved massive scale because they can absorb these costs. Even the most well-funded ventures are capital-poor in comparison to Big Tech. When a new technology is expensive to build and operate, [economies of scale](https://www.investopedia.com/terms/e/economiesofscale.asp) are challenging to achieve. This puts startups at a massive price disadvantage to big businesses willing to lose money in a market. 

Significant capital is required to train a new AI model. It is also expensive to operate a model after it has been trained. This is why OpenAI's APIs are costly in comparison to other cloud services. It is also why companies like Facebook and Google have had reduced profitability as they've come to depend more on AI. Each AI-powered operation has a high fixed cost, which means startups that rely on AI will struggle to achieve economies of scale compared to other software businesses.

The current state of AI looks a lot like what Clayton Christensen would call a *sustaining technology*. A sustaining technology is one whose value is likely to be captured by current Goliaths (maintaining their monopoly), as opposed to a *disruptive technology* that will usher in a new generation of Goliaths.

Successful technologies offer a solution with a dramatically better return on investment than what was previously available. Because AI products are more expensive to operate than traditional SaaS products, they must offer much better solutions to be worth the additional cost. If a SaaS solution already solves a problem cheaply, it is trivial for them to add a layer of intelligence and absorb the additional costs. This is why startups should not aim to disrupt existing software businesses by building similar products with a layer of AI. 

Startups should instead focus on solving neglected problems that were previously impossible or incredibly expensive to solve with software. If a problem is currently unsolved or only solved through expensive (manual) effort, there is an opportunity for you to disrupt. While SaaS has digitised existing business operations, the best opportunity for AI startups is to completely automate them, because this is where cost savings will be greatest for customers. For example, many highly paid jobs are mostly research and synthesis (*e.g.,* analysts, lawyers, even GPs). AI can do these jobs much cheaper than professionals.

Running models on device is another opportunity for startups. Many established SaaS companies are all-in on cloud computing. Running AI models in the cloud is expensive. But models like Stable Diffusion run great on mobile devices (Apple has even optimised their operating systems for Stable Diffusion). Native mobile apps that run AI operations on device will have dramatically lower costs than cloud-hosted AI apps. The output of these local models may be worse, but it is likely to improve. The on-device strategy sounds more like a disruptive technology (currently worse, but cheap and rapidly improving). If this ends up being the winning strategy, cloud-based SaaS startups will take time to pivot. This creates an opportunity for startups to disrupt.

Tags: advice, startups, ai, strategy

# Fostering focus as a founder

Founders take on a massive workload during the early stages of startup building. Someone needs to do the functions of the business that don't yet have teams (sales, support, customer success). So, founders take on this work. In early-stage companies, founders not only set the vision but also execute it, often down to the detail. This workload can take a toll, but it also gives founders a lot of control over what gets done and how. It also builds creativity — leaders who succeed in this phase often make it because they can come up with ideas to solve diverse problems independently.

As a customer base grows, so does the team that supports it. Eventually, whole departments represent each function of the startup. The role of the founder evolves. Leaders are now solving a few big problems (growth, recruiting key leaders, setting the vision) instead of many small problems. Success is no longer driven by the number of good ideas a founder can come up with. Success is driven by the execution of the few fantastic ideas that undergird the growing business.

In my experience, many founders struggle with this transition. Some struggle to trust the leaders they've recruited to own departments like sales, marketing, product, or customer service. Others struggle to focus their energy on the right problems. For most, new ideas keep coming, and this breaks the focus of the organisation. 

Ideas, even great ones, are cheap and easy. Execution towards outcomes is difficult and expensive. New ideas are great if they solve the right problems. If they don't, they split the focus of your team and make it more difficult to execute on what is important. When you multitask, outcomes become mediocre.

The insidious thing about focus-splitting is that it happens naturally at all levels of the organisation. Meaning even if founders resist the urge to inject new ideas into the mix, leaders and contributors at all levels of the organisation will do it for them. It's not enough for founders to be focused. They must foster focus throughout the organisation.

> *"The best thing founders can do is subtraction."*
> — Tobi Lütke

[Research shows that people systematically overlook subtraction as a solution](https://brandon.uno/links?post=480297550). This means that almost every time a problem is solved within your organisation, it is solved by a new process, feature, product, or hire. All these solutions increase the overhead costs for your business. Distractions turn into bigger distractions. Organisations move slower as they grow. So, for an organisation to be focused, leaders must be actively engaged in the exercise of subtraction. They also need to build a working culture that encourages focus, radical prioritisation, subtraction, and simplification. **Subtraction might be the only thing that you can do, as a startup leader, that nobody else is going to do for you.**

All startups need to be focused on a few specific tasks. Leaders of startups that have not yet achieved product-market fit should be focused on finding the right solution, to the right problem, for the right market. They do this through [product development](https://fastertim.es/post/finding-and-measuring-product-market-fit) and [sales experimentation](https://fastertim.es/post/sales-product-market-fit).

Leaders of more mature startups should be focused on scaling their product into the market. They do this by [making their product easier to adopt](https://fastertim.es/post/how-to-achieve-terminal-velocity), [exploring new sales strategies](https://fastertim.es/post/sales-product-market-fit), and [improving business operations](https://fastertim.es/post/build-simple-self-improving-systems). Avoid the trap of more. Don't build a second product. [Don't bring your product down-market](https://fastertim.es/post/why-its-so-hard-to-move-down-market). Enter new geographies with caution. If the market likes what you have, all of your energy should go towards giving it to them. 

If the market doesn't like what you have, all of your energy should be invested in finding a better solution, problem, or market.

Tags: advice, startups, highlights

# Why it’s so hard to move down-market

Great startups pivot. As they build and sell products, they validate and invalidate their assumptions. Most importantly, they learn from this new information and change tact.

The most significant startup pivots regard product-market fit. For example:

- Market — changing your target market.
- Problem — choosing a different problem to solve for your target market.
- Solution — finding a new way to solve the problem you've targeted; transforming the product.

Many founders believe they can perform one of these pivots while continuing to focus on their existing market, problem, or solution. So, instead of "let's do this instead", they say, "let's do this as well". In general, startups should [remain focused on one solution to one problem for one market for as long as possible](https://fastertim.es/post/how-to-achieve-terminal-velocity). This focus is the way you can best maximise growth for your business. But today, I want to explore the two most tempting pivots for B2B startup founders.

## Moving down-market

Almost every founder I have worked with has had the idea to expand their total addressable market by moving down-market. Most markets have many small businesses and fewer larger businesses. So, it's logical to target the smaller end of town so you can acquire a greater number of customers.

However, if you have already found product-market fit in your current market, it is challenging to move down-market. This is because:

- Large customers require more product complexity. This product complexity causes user experience problems for smaller customers. The implications of this are:
	- Smaller customers will be difficult to sell to because they would rather use something that is easy to use. By initially targeting larger customers, what you have built will not meet this requirement.
	- Smaller customers will be onerous to support. As they are less prepared for a complex product, you will need to hold their hands more.
	- You will need to dedicate significant resources to simplifying your user interfaces before you can effectively sell your product to smaller customers.
- Servicing small businesses is less profitable. This is because they need more support (even when user interfaces are perfectly designed with them in mind) relative to what they can pay you.
- It is difficult to simultaneously build products for these smaller customers and your existing larger customers. Their needs rarely align, so most of the user experience improvements you need to prioritise for your new smaller customers will clash with the more advanced functionality needs of your larger customers. This splits your focus and pulls you in two different directions. Often, you end up neglecting at least one of these cohorts.

In contrast, it's relatively easy for software startups to move up-market. Or, it's easier to target new prospects larger than those you traditionally target. This is because:

- The natural momentum of all software products is to move up-market as products become more capable over time. Your existing customers are growing and therefore asking for new features that cater to their now larger businesses. This aligns perfectly with the features that larger prospects need.
- User experience is easier to evolve when you're adding complexity than when you're removing it. It's easy to add new features in a way that ensures additional complexity is only disclosed to users who need it. It's tough to do this retroactively.
- Moving up-market improves profitability. Larger customers are willing and able to pay more, and while they may require more support, this rarely scales linearly with their software fees. This makes these customers proportionally cheaper to service.
- Larger customers have greater means to overcome product challenges. If a large customer needs a feature you don't have, they are more likely to be willing to pay a third party to develop something using your APIs. This reduces the need to build everything in-house.

This is why I advise startups with sufficient runway to target their **smallest viable customer**. The smallest business that they are likely to ever want to target. Starting at the bottom end of town makes it much easier to grow your business and your product while progressively targeting larger customers. 

I also recommend the following:

- When you want to expand your addressable market by targeting a new audience, always try to move up-market.
- Don't move up or down-market too early. Either of these changes can be distracting if you implement them before it is necessary.

The best reason to move down-market is to avoid disruption. Because it is easy to start simple and progressively add complexity, competitors who start down-market from you can catch up to you quickly. They are better positioned to do this than you are to move down-market, which is why I think the best way to move down-market is to create a new product and disrupt yourself. Starting fresh often (though not always) is easier than trying to devolve your existing product. At the same time, this is a massively expensive undertaking — you should only do it when you are large enough to take this on in parallel to the maintenance of your original product.

Note that this is potentially the only time it makes sense to start from scratch. Other motivations for a fresh start (*e.g.,* to improve your technology stack) are often bad ideas, with progressive evolution being the preferred approach.

## Solving additional problems through new products

It is logical to think that you can drastically grow the total addressable market for your business by building a second, third, or fourth product. This idea is supported by the fact that most highly successful companies sell more than one product.

I completely agree with this logic. Creating new products to sell to your existing customers makes a tonne of sense. This is a great way to earn more money without having to acquire net-new customers — [this cost-effective growth is one of the best things about the SaaS business model](https://fastertim.es/post/optimising-pricing-for-revenue-expansion).

Timing is where most startup leaders get this wrong, though. By prematurely expanding into additional product lines or trying to sell their existing product to another market with a slightly different use case, they dilute their focus from a product development and customer acquisition perspective. The primary risk here is opportunity cost: by taking on something new, you're neglecting improvements to your core product which could lead to better outcomes.

The best time to start to build new products is when you are earning enough from your core product that it is beginning to feel like you don't need as many people as you can afford. A close second is when you're starting to feel like you're at risk of exhausting your current target market. If you wait until one of these criteria is met, you can expand your suite without harm to the existing business opportunity.

Tags: advice, startups, highlights

# Strategies for recurring revenue expansion

SaaS startups should aim for the recurring revenue they earn from each customer to grow over time. This is one of the critical responsibilities of your customer success function. Some startups have a hands-off approach to renewals, whereas others choose to be more hands-on. This dramatically impacts the mechanisms available to you for driving recurring revenue growth.

A hands-on strategy is one where your team is individually engaged in the renewal process for each customer. This works best for more expensive and specialised products (*i.e.,* startups earning a lot of money from a relatively small customer base). Because each standalone customer is highly valuable, these startups can afford to manually handle each renewal, which may only come about once a year and could result in a notable recurring revenue uplift.

For these startups:

- Customers often commit to an annual or multi-year contract when they signup. Payments may be collected annually, monthly, quarterly, or on another schedule. A salesperson is likely to guide the purchase process.
- Before each contract renewal, a customer success agent facilitates the renegotiation of the contract with the customer. The customer success agent aims to both retain the customer and increase the price they pay for the product.
- These contract renegotiations allow customer success agents to upsell additional features to each customer.

In contrast, a hands-off strategy is one where the renewal process for each subscription is automated. This works best for more affordable products that target a broad market. Because these startups have many customers who don't individually contribute much towards total ARR, these startups can't afford to manually handle each renewal, which is often on a monthly cadence.

For these startups:

- Customers likely subscribed to a monthly plan through a self-service signup flow.
- Any discounts are coupons or limited-time marketing promotions.
- Renewals happen automatically each month.
- Upselling is done through low-touch marketing efforts.

While it seems intuitive to say that self-service (*i.e.,* bottom-up or product-led) SaaS products should have a hands-off approach to renewals, this is not always the case. Many self-service SaaS products succeed by removing the barriers to initial product adoption while still taking a hands-on approach to sales and renewals. Essentially, the self-service experience gets your foot in the door while the real money is made through a more traditional sales process that follows. This is why I think the price point is the defining factor rather than the sales/service model.

Regardless of whether your startup employs a hands-on or hands-off approach, these are the critical things to consider for revenue expansion:

- Pricing is the most essential foundation for a revenue expansion strategy. [Make sure you address this first](https://fastertim.es/post/optimising-pricing-for-revenue-expansion).
- **Upselling of features.** Because the SaaS model ensures an ongoing relationship between software vendors and customers, these startups are well-positioned to upsell new features and products to their existing customers. Some startups do this during one-on-one negotiations, while others depend exclusively on one-to-many marketing strategies.
- **Reduce discounts over time.** Discounts and offers should ideally expire automatically. It's better to offer customers a 20% discount for six months than a 10% discount for twelve because the former will expire before the contract renews. Otherwise, you will need to factor discount reduction into your negotiations with each customer.
- **Increase base prices roughly every year.** This will keep your prices in line with inflation and the improved functionality of your core product. Some startups do this during one-on-one negotiations, while others communicate price changes via one-to-many means. Note that increasing pricing regularly in small amounts is much easier than irregularly by more significant amounts.

Ultimately, delivering new value is the best way to grow revenue from existing customers. As their needs grow, so should the value you bring to the table. This is why many SaaS companies move up the market over time, gradually targeting bigger and bigger businesses. Because your existing customers are growing and their needs are expanding, your customers will pull your product in that direction. This not only ensures that you can retain your customers and charge more for your product, but it also enables you to sell to more sophisticated prospects.

Tags: advice, startups, sales

# Optimising pricing for revenue expansion

As B2B SaaS startups achieve scale, they can achieve massive revenue growth by better monetising existing customers. In the early days, startup leaders are often too focused on building their product and selling it to new customers; expansion revenue is an afterthought. Fortunately, through strategic pricing, you can make this revenue growth easy before you've had the chance to invest in customer success.

> Expansion ARR/MRR is additional recurring revenue gained from existing customers (*e.g.,* plan upgrades, purchasing additional products).

**The best way to foster expansion revenue is to lay solid foundations in your pricing and product strategy.** There are several ways you can encourage revenue from existing customers to expand without any manual handling or 1:1 interaction with your customers. You need to find ways to align *the price of your product* with *the value it delivers*. The bigger a customer is, the more value they get from your product, and the more they should pay for it. If you charge this way, you can ensure that customers who cost you more to support also pay you more. More importantly, this ensures that as your existing customers grow, they will naturally pay you more.

First, consider **usage/volume-based, or transactional pricing**. Price your product based on how actively your customers use it. This can serve as a proxy for the size of each customer because bigger businesses will likely engage more with your product. As existing customers grow, they will naturally pay you more. This is most commonly achieved by charging an additional fee (*e.g.,* $5 per month) for each user, though this often fails because, for many products, it is trivial to share user accounts. 

When usage is consistent month-to-month and grows gradually, it makes sense to charge your customers with an ongoing subscription, with multiple plan levels influenced by how much each customer utilises your product. For example: 

- Many analytics platforms charge by the volume of data (or visitors in the case of web analytics) stored in the system. Larger companies will have more data, thus, will pay more.
- Ecommerce platforms commonly offer different subscription plans for different orders or revenue volumes. For example, the more orders processed by a warehouse management system, the more it will cost.
- Tax compliance products like TaxJar charge by the number of tax calculations. 

Alternatively, a real-time transactional model may make sense for products or features where usage varies drastically month-to-month or where marginal costs are tied to each transaction:

- Products built around payments, like Shopify, charge transaction fees. This is because these companies incur marginal costs for each transaction. Even Shopify is paying someone else for each payment (Stripe, who also has fees to pay), so by charging for each transaction, they can ensure they always turn a profit no matter how much each customer utilises the product.
- API-as-a-service products charge by API calls because this is a simple way to align the cost-to-service of each customer with the amount they pay. If these companies charged a simple subscription, they would likely lose money on customers who demand a lot from their APIs.
- Marketplace products like Uber or AirBnB charge for transactions for similar purposes. Additionally, a mandatory subscription for these products doesn't make sense as it would serve as a barrier to entry for users.

Subscription and transactional models both have downsides. Subscriptions provide consistent and reliable revenue, even when usage temporarily drops (due to seasonality or even during recessions), while they make it difficult for low-usage customers to give the product a try and can make it more challenging to monetise the most active customers maximally. Transactional models can better monetise the value being delivered and align revenue with costs, but revenue can suddenly plummet during slowdowns. This is why it is a good idea to try to offer both. Even Uber, which has traditionally had a transactional model, now offers a subscription service for power users.

Second, it may make sense to **charge additional fees for power user features**. B2B SaaS products tend to target a market of businesses that vary wildly in size. Naturally, as your product matures and your individual customers grow, you will start to build features that are well-suited to large customers, but small customers don't need them. It might make sense to charge additional subscription fees for these products. This is another way to grow recurring revenue as your customers increase their utilisation of the product. This can be a risky strategy, though. If you monetise the growth of individual customers through usage-based pricing, additional fees for features that help your customers to grow could limit your own growth. One rule of thumb that has worked for startups I've worked with is to charge for features that reduce operational costs and give away any feature that increases customer revenue (or utilisation).

Whether you are charging usage-based subscriptions, transactions or charging for individual features, it is critical to align the success of your customers with your pricing. By only charging more when customers receive greater value, you align the incentives of your startup with customer success. It is much easier to ask for more compensation from your customers when you are providing more value. These aligned incentives also make it easier to prioritise your product roadmap. If, for example, you make more money only when the businesses who use your product grow, you will be naturally incentivised to improve your product in ways that will encourage this growth.

Tags: advice, startups, sales

# Should SaaS products offer free trials?

While it is well understood that great self-service products grow faster, many startups start with a high-touch sales and onboarding experience. Why build a slick onboarding experience for an unproven product, after all? As these startups mature, though, startup leaders realise they could grow much faster with a self-service experience, which becomes a product development priority.

The onboarding experience for each software product sits somewhere on a spectrum between self-service and high touch:

- Users of a self-service product can trial, configure, and purchase the product independently without assistance. 
- Users of a high-touch product need assistance at every step. They evaluate the product through a live demonstration, pay for professional configuration services, and purchase it through negotiations with a sales team.

A self-service experience, including a free trial or freemium plan, is a cost-effective way to sell a product that is capable of selling itself. It's cost-effective because you need fewer sales and onboarding employees per deal if customers can do it all themselves. Growth without the bottlenecks that come with any required 1:1 interaction between their team and their customers is the primary reason startup leaders want to move towards a self-service experience. Before doing this, it's important to consider whether your product is ready.

At the start of the customer journey for your product, your goal is to convince prospects that your product is the best solution to their problems. Consider this goal when deciding whether to move towards a self-service experience. **Would a free trial and/or a self-service product configuration experience do a better job of selling your product?**

For some products, the answer is yes. These products solve a big problem for a big market. Their solution is differentiated, easy to understand, and easy to configure. The pathway from the discovery of the product to receiving value from the product is clear and simple. For other products, this is not at all the case. A self-service onboarding experience, and even free trials, can make your product harder to sell. If your product doesn't speak for itself, you might need a sales team to speak for it. I've even seen startups move away from self-service experiences to achieve better growth results.

While there are no strict rules that determine whether a self-service experience is right for you, the following prompts may help:

- Consider how valuable each sale is (*i.e.,* Average Revenue per Account) to your business. The more valuable each sale is, the more you can afford to invest in sales and onboarding.
	- If your pricing model will require you to have thousands of customers to achieve $10m in ARR, you're building a high-volume SaaS startup. SaaS products that depend on high-volume sales should be as self-service as possible. 
	- If your pricing model will require you to have just a few hundred customers or less to achieve $10m in ARR, you're building a low-volume/enterprise SaaS startup. A more high-touch approach might be acceptable.
- Consider how challenging it is for users to receive value from your product.
	- Products like Slack deliver value very early in the customer journey. You simply invite your colleagues and start collaborating. A high-touch experience will only slow these products down. You should offer a self-service trial.
	- Products like Salesforce require a tonne of configuration to deliver value. Most users are not capable of doing this configuration themselves. For these products, a free trial is more likely to scare customers off. They should instead lead with a 1:1 demo.
	- Some products sit in the middle. They can deliver some value quickly but require more configuration to deliver all of the value they can deliver.

All startups should strive to be as self-serviceable as possible. When tackling this problem, I recommend reviewing the customer journey for your product in its entirety. Where are the biggest bottlenecks? If growth quintupled, what would break first? The biggest bottleneck is rarely free trial signup. For example, it doesn't make sense to offer a free trial when configuration is next to impossible because it is a bigger bottleneck. Keep doing demos for new sales and instead improve the configuration process. When users can self-service their way through configuration, offer a trial to get them to that step. 

While a full self-service experience might not make sense for your product, you should always be improving the onboarding experience for your app because this is one of the easiest ways for others to disrupt your startup. A product that can grow faster than yours, even if it has fewer features, can rapidly take market share from you. Small competitors who grow quickly are more likely to disrupt you than large competitors who move slowly. Functionality moats may shield enterprise SaaS startups from these competitive pressures for longer, but these pressures eventually catch up to everybody. 

If you're struggling to find a path towards a self-service model, reconsider who you're selling to. Stripe, for example, requires a lot of work to set up — usually, the customer must write some code. Despite this complexity, Stripe grows through a self-service experience by targeting developers and has optimised its marketing and onboarding experience almost exclusively for this audience. Similarly, many ERP, CMS, and ecommerce platform products grow by targeting professional services companies who can sell and service products for them.

Tags: advice, startups, highlights, sales

# How SaaS companies can survive recessions

For many SaaS companies and startup leaders, the 2022-2023 recession will be their first. Fortunately, we can learn a lot from bootstrapped startups. Thanks to their lack of VC funding, leaders from bootstrapped startups have first-hand experience growing companies in an environment of capital scarcity. Having been in these trenches, I wanted to share some specific and actionable advice.

First, startup leaders need to implement austerity measures early:

- A company with $2m in the bank and a monthly burn of $250k can only last eight months. 
- Reducing burn to $100k will give you twenty months of runway — a much better situation given the average recession lasts eighteen months. 
- If you wait a few months to see what happens in the economy before enacting change, your runway will unnecessarily evaporate. Waiting four months before cutting monthly spending to $100k will only afford you ten months of total runway — a meagre improvement from your original position.
- Therefore, inaction is potentially very costly. If your startup is burning cash at a rate that doesn't afford you at least twenty months of runway and fails to make changes quickly, you may have to cut costs far more dramatically when the time eventually comes. Worse, you could end up with no pathway towards enough runway to weather the storm. 

In addition to timing, startup leaders need to be mindful of how much they need to cut costs to make it through a recession. Measure twice, cut once, and be transparent with the remaining team: let them know what position the business is in now that costs have been reduced. This is the best way to keep your team engaged after a traumatic event and maintain their confidence. Failure to cut costs is the biggest mistake of leadership teams in a budget crisis. Suppose your pathway towards profitability, or enough runway to survive a recession, requires a reduction in force. In that case, this will inevitably negatively impact company culture for the remaining team. Individuals will be concerned for their job security. This consequence is significantly amplified if, in the future, you further reduce the team size. Suppose you don't solve the runway/profitability problem through your initial reduction in force. In that case, your remaining employees could lose confidence in their job security and start to look for other opportunities.

If you are profitable or already have enough runway to survive an extended recession, consider implementing a freeze on hiring or any other significant new costs. Delaying new expenses for a few months could allow you to make it through the recession without any drastic cost-cutting initiatives. If you hire now and the recession gets much worse, you could have to reduce the size of your workforce soon, which could have severe cultural implications for your team.

Make sure you consider every available option in terms of reducing costs. For example, SaaS startups typically spend vast amounts of money on other SaaS products. Hosting and infrastructure vendors tend to deliver hefty bills, too. Many startup founders I've worked with struggle to negotiate better pricing or terms with these vendors. If this is not your strength, find someone to help you with negotiations. Someone on your sales team could be better at contract negotiations than your engineering team. Additionally, this is a fantastic way to ask your investors for help — they will likely be more than happy to lead these negotiations on your behalf.

From a product perspective, now is the time to consider your value proposition in a recessionary economy. Most businesses, including your customers, have been in growth mode in recent years. Mindsets are now shifting towards survival mode. How you present your value proposition to existing customers needs to reflect this shift. Many of your customers will reconsider each vendor's importance to reduce operational costs. You must be ready to make a case for why your product is essential and should not be dropped from their toolkit. One way to do this is to adjust your value proposition to highlight how your product reduces operational costs by automating and streamlining manual processes. You should update your website to reflect this, and outbound marketing to existing customers should start to tell this story.

Another way to assert the value of your product is through analytics. If your product can be shown to provably increase revenue or reduce operational costs for your customers, highlight and celebrate this. The dashboard for your product, your email marketing, your customer success calls, and your website should all empirically outline the value your product is bringing to your customers, both individually and collectively. If you assert the value of your product in a measurable way, it will help customers to appreciate their need for it. A business trying to cut costs won't turn off a product that they are certain is saving them money.

Even if they know your product is highly valuable, your customers will try to renegotiate their contracts with you in a recession. Usually, it is better to give your customers a deal so that you can retain them through the tough times, even if it means they pay you less for a while. But, throughout this process, make sure you use these negotiations as an opportunity to protect your business. For example, negotiating for longer contract terms can be beneficial during tough times. If a customer believes in the value you bring and is getting a good deal on price in exchange for an annual contract, they are much less likely to look for cheaper solutions during the recession. It could even be a good idea to start these negotiations yourself rather than wait for your customers to come to you, particularly for key accounts.

When tackling churn, be sure to consider unit economics. You may have customers who are paying very little for your product and may even cost more to host and support than what they contribute to your revenue. Try to quantify this, and use it as a guide for how to handle customer churn. Occasionally, customer churn can have a positive impact on the profitability of your company.

- Many bootstrapped startups rely heavily on professional services to pay the bills while recurring revenue slowly builds to sustainable levels. If this isn't already a significant revenue stream for your business, now might be the time to consider how services could bring in more revenue from new and existing customers.
- Organic marketing and customer referrals are very cost-effective ways to grow. If you haven't focused on these channels in the past, consider doing so. Improve the SEO of your website, repurpose your support documentation for content marketing, and incentivise your current customers to send more business your way.
- Usage-based SaaS businesses tend to better monetise their customers' success when compared with subscription-based SaaS companies. At the same time, this makes revenue for these businesses especially vulnerable during a recession where many of their customers are less successful. For example, a startup that earns revenue for every order submitted through its system will see shrinking revenues as order volumes contract through a recession. Usage-based SaaS businesses should consider ways to diversify their revenue streams, potentially by adding subscriptions to the mix.

Lastly, and on a positive note, consider the upsides of startup building during a recession. Leaders who move quickly and ensure their startup has ample runway will be well positioned to continue to invest and build their startup during a time when many of their competitors are not. Startups that are forced to consider the potential for profitability from early on tend to build more robust businesses. Big Tech layoffs will make it easier for startups to recruit top-tier talent at an affordable cost. Many of the greatest technology companies were built during tough economic conditions. If you take this challenge seriously, your startup may emerge from this recession stronger than ever.

Tags: advice, startups, highlights

# How to achieve terminal velocity

Product-market fit is the first challenge for startup builders. While this is when most startups fail, [the playbook is relatively simple](/topics/strategy): build, get feedback, learn, and iterate until customers love your solution to their problem. Hopefully, your product will eventually solve a big enough problem for a big enough market, and you'll be ready to scale your startup. This is where the playbook gets a little less clear.

You know you're achieving product-market fit when selling your product is relatively easy. Frankly, this is when many startups become mediocre because strategy simultaneously becomes *more important* and *more difficult*. 

You can no longer cut corners. This is why strategy is especially critical for startups with mature products. The effort required to build new features is more significant because your existing customers need a reliable product. Some new features will dramatically increase your addressable market. Others will have no impact. The effort required is identical regardless of impact, so making the right decision is critical. Even seemingly great ideas can turn into expensive wastes of effort.

For these same companies, strategy is more difficult because mature startups can no longer allow sales prospects to dictate their roadmap. Suddenly, real work is required in order to decide what to do next.

Frustratingly, this is also when software maintenance becomes burdensome. The more customers you have, the more they will test the limits of your product. So, as most software startups mature, they experience resource constraints thanks to an increased maintenance burden. The increasing maintenance burden and the need to build higher-quality software results in founder frustration: "*we have more engineers, but we are getting less done"*.

> Product strategy is critical in this environment where the cost of a misstep is ever-increasing.

Any development that shortens your sales and onboarding cycles should be your priority. A business that can turn a lead into a happy customer in one month will grow dramatically faster than a business that can only do this in two or more months. Optimising your onboarding experience and improving existing features is usually better than adding new ones. The compounding impact this investment can have on your revenue is significant. Many founders make the mistake of attempting to expand into new markets with new products before their first product is growing at terminal velocity. You must remain focused on this goal until it is achieved.

Similarly, mature startups need to invest in the scalability of their technology by optimising existing features. Many startups at this stage view maintenance as an unwanted burden. But, continuously optimising the functionality, usability, and reliability of your existing features compounds into tremendous business value over time. Your customers use your product because of the features you've already built, not future features they imagine might be coming. It makes sense to make them even better, while improving the underlying technology (performance and reliability are features, too).

Stay focused. That is the core of my message to maturing startups. Almost every idea, if executed now, will become an unnecessary distraction from your mission to sell what you have already built.

Every successful startup should eventually invest in more radical initiatives. This makes sense when:

- You are starting to saturate your target market. Now it makes sense to build features or even entirely new products that expand your total addressable market. While this usually takes a while, it can happen early in the lifecycle of startups that are hyper-focused on a tiny niche.
- You are earning so much revenue that your product development budget is greater than what is necessary to optimise and expand your core product. This is when it makes sense to build additional apps that you can sell to your existing customers for additional ARR, or to expand into other markets with new features or products.
- Your core product is facing severe competitive pressures or is otherwise being disrupted. If the market moves in a drastically different direction, startups need to pivot.

Startup leaders witness the founders they admire launch new products and expand their total addressable market with new features. This can give them the impression that this is how you win as a software startup. In reality, the companies who pull off these pivots and risky investments do so because they have first invested in unleashing the growth potential for their core product. Similarly, they witness their competitors launching new features and think they need to do the same to stay competitive. In reality, when these features distract from the core offering, they could be a sign that your competitors are failing strategically, not succeeding. Remaining focused is how you will outpace the competition. To achieve terminal velocity, you must constantly optimise your sales and onboarding funnels through product development. Everything else comes later.

Tags: advice, startups, highlights

# Grow faster with a vertical SaaS strategy

Vertical software-as-a-service products target an industry or business model niche. They are vertical because they go deep by solving problems at multiple layers of their customers' technology stack. For example:

- [Shopify](https://www.crunchbase.com/organization/shopify) is a vertical SaaS product that targets ecommerce businesses. They go deep and solve many different problems for this market, from payments and shipping to inventory management and marketplace integrations.
- [GitHub](https://www.crunchbase.com/organization/github) is vertical because they focus on solving the various problems software engineering teams face.
- [ServiceMax](https://www.crunchbase.com/organization/servicemax) is vertical because it caters to the various needs of field service companies.
- [Toast](https://www.crunchbase.com/organization/toast) provides various solutions for hospitality businesses, making it a vertical SaaS company.
- [JustGiving](https://www.crunchbase.com/organization/justgiving) is vertical because it narrowly focuses on charities and fundraising endeavours.

Horizontal SaaS products are horizontal because they target a wide range of businesses that are trying to solve a common problem, regardless of their industry. For example:

- [Slack](https://www.crunchbase.com/organization/slack) is a horizontal SaaS product that solves the communication problem commonly experienced by all businesses. They don't target any specific vertical and only aim to solve challenges within the communication domain. They cast a wide net from a customer acquisition perspective.
- [QuickBooks](https://www.crunchbase.com/organization/intuit-quickbooks-small-business-2) is a horizontal SaaS product that aims to handle the bookkeeping needs of all small and medium-sized businesses. 
- [HubSpot](https://www.crunchbase.com/organization/hubspot) is horizontal because they help sales forces within all industries to grow and manage their work. 
- [TaxJar](https://www.crunchbase.com/organization/taxjar) solves the sales tax problem for businesses of any business vertical, from online retailers to SaaS companies, making it a horizontal product.

Most SaaS businesses need to make an explicit decision between the two models before they stumble into a vertical or horizontal SaaS strategy. Otherwise, you may experience a lot of operational pain because the best way to build and grow these businesses varies greatly. By understanding the differences between *vertical* and *horizontal* SaaS strategies, you can better position your company for long-term success.

Growing a horizontal SaaS product is typically more difficult, but the long-term total addressable market is much larger. Horizontal SaaS products have more significant addressable markets because they solve a problem experienced by many more businesses. Growing a horizontal SaaS business is difficult because there is usually more product competition (if most businesses experience your problem, many others have likely had the idea to fix it) and even more marketing competition (because your target customer is extremely broad, your marketing team must compete with companies selling completely unrelated products). So, while you are much less likely to succeed with a horizontal product and growth strategy, if you do, you can build a much larger and more valuable business.

It is easier to build and grow a vertical SaaS product because:

- Your target customer is more clearly defined. 
	- This means your customers likely have a lot more in common, which makes it easier to build features that many of your customers will use. Customer feedback is much more valuable and actionable in vertical SaaS businesses. Strategy is easier.
	- It also means your marketing efforts can be more targeted, which leads to lower customer acquisition costs with better return on investment.
- You will face less competition. This allows you to grow quickly with an imperfect product, because imperfect solutions are better than no solution at all.
	- This also protects you from Big Tech disruption. Large companies like Microsoft and Google typically only enter very large markets and cannot justify delivering niche solutions. [If your product isn't sufficiently niche, a larger company could disrupt you](https://twitter.com/0xWavyDon/status/1586503905567191040?s=20&t=dlGeSFSwzkqOAo5t7Yhyyg) by shipping a worse but cheaper version of your product (see: Microsoft Teams).
- You can likely charge more. If you focus on a niche, you can thoroughly solve big problems. You can charge more for your solutions if you deliver a lot of value.
	- Horizontal companies often compete on price. As you succeed, others will enter your market with a worse but cheaper product, eventually causing a pricing race to the bottom.

Most SaaS businesses set out to solve a specific problem and grow by either solving more problems for their early customers (*i.e.,* scaling vertically) or trying to sell their solution to more diverse businesses (*i.e.,* scaling horizontally). When startups struggle to scale beyond initial product-market fit, it's often because they are trying to scale horizontally when a vertical focus makes more sense. 

*Horizontal versus vertical* is more of a spectrum than a binary state. Markets contain solutions with varying levels of niche, existing somewhere on the spectrum between horizontal and vertical. For example, one startup might focus on all businesses who need a payment provider, another might focus on SaaS businesses, while a third might focus very specifically on SaaS businesses with usage-based pricing. In these markets, the more niche product will easily win deals that fit nicely within their niche, while the more horizontal company will absorb those with simpler needs or whose niche has yet to be catered to.

While gradually going more horizontal can make sense for a startup that is starting to exhaust its' original target market, many startups do this prematurely. Early-stage startups often struggle to reject prospective customers who don't fit within the niche they are targeting. By onboarding these customers, they gradually expand their target market before their product or growth strategy is ready and lose focus on satisfying their ideal customer, which can slow growth.

Whether you choose a vertical or horizontal strategy, focus is still critical for a startup. Horizontal startups need to focus on the core problem they are trying to solve, while vertical startups need to focus on their niche market. It pays dividends to have a clear idea of who you want to target, what problem you want to solve, and what distractions you want to avoid. Otherwise, your product could end up too shallow to satisfy your nich,e and too narrow to cater to a broad market, which could trap your startup in stasis.

Tags: advice, startups, strategy

# Team rituals for continuous improvement

As your startup grows, responsibilities that used to belong to a single individual will be owned by teams and, eventually departments. This transition is where startup operations become critical. Things that used to be easy to achieve without procedures or policies become increasingly ineffective and complex as teams grow, and standardisation/operational innovation is usually the solution. So, while building teams starts with recruiting and fostering great talent, establishing sensible and effective ways of working is increasingly important as your team grows and their responsibilities become more complex. As new teams emerge within your startup, rather than sticking to what has always worked (or the way the progenitors of each team worked), you should adopt practices and rituals for self-improvement.

Self-improvement starts with metrics. For some teams, it is easy to measure effectiveness because feedback loops (*i.e.,* the delay between action and outcome) are tight. By measuring effectiveness, you can quantify the positive or negative impact of any changes to your ways of working. For example:

- Customer Service teams can be measured by how many support cases they can complete, which can also be broken down by individual or sub-team. You can also quantify their effectiveness by measuring how long it takes to respond to support cases, how many responses they submit to resolve a customer problem, and how satisfied customers are with the service they receive (*i.e.,* CSAT). 
- Account executives can be measured by how many deals they close, the revenue value of these deals, the average size of each deal, how long it takes to close deals, and how likely the customers they sell to are to churn.

Tracking metrics like these will allow you to identify opportunities for improvement and observe how changes to your ways of working impact your team's effectiveness. They also empower you to compare different individuals in similar roles to identify personal habits that do or don't work. For example, you might notice that your account executives who mention pricing early in the sales process have a worse conversion rate but close deals much more quickly, ultimately leading to better results because they can filter out prospects who cannot afford your solution early in the sales cycle. Over time, performance baselines will emerge from metrics like these. You'll know that effective customer service staff should be able to resolve a certain number of support cases each month, making recruiting, onboarding, and individual management much more straightforward.

Beyond metrics, there are several team and individual management rituals that promote self-improvement. While these will vary by startup and team, I recommend considering the following rituals:

- 1:1s between managers and individual contributors can be a critical venue for coaching. I've found that these work best when employees rather than managers lead them. This format empowers employees to manage their workload and outcomes, relying on their manager for support. When managers lead 1:1s, they often turn into delegation sessions with the individual contributor in the passenger seat.
- Team-wide retrospectives are opportunities for teams to reflect on results and propose strategic and operational improvements. For these sessions, it's valuable to look directly at the data: review your metrics or backlog in real-time rather than reflect on how you felt things went. These should occur regularly (_e.g.,_ each sprint or month), and you should organise ad-hoc retrospectives (_i.e.,_ post-mortems) after particularly disruptive incidents.
- Peer-to-peer work reviews. Individual contributors should review each other's work. For example, engineers should review each others' pull requests, and support agents should monitor each others' calls for call coaching. While many managers will try to own this work for quality assurance purposes, doing so relies too heavily on the availability of managers, is challenging to scale, and deprives individual contributors of a pivotal opportunity to improve their technical and leadership skills.

As a leader of a single team or division, it can be tough to affect change in groups other than your own. However, for your startup to improve, every team needs to be responsive to feedback from customers, the market, and internal stakeholders. Many teams struggle because they receive much more feedback than they can reasonably respond to. This challenge is tough when feedback is given in an anecdotal format because it is difficult to equate individual anecdotes with real business impact. As a team leader, you should make it easy for other teams to give you feedback in a format that will be useful. Similarly, if you're struggling to convince other teams and leaders to take your input seriously, try to capture and format your feedback in a way that will be valuable to others. For example, it's difficult for product managers to prioritise new features based on anecdotes about lost sales. By instead capturing product feedback against every lost sale in your CRM, you can empower yourself to make a well-informed argument for how the development of a particular feature could impact the business. By taking a data-driven approach to collecting feedback for your team and handling feedback you provide to others, you will better encourage change across groups.

Lastly, teams that receive a lot of inbound work from others should embrace asynchronous backlogs. By receiving requests via chaotic means like email, messages, conversations, and calls, teams are constantly disrupted by demands and spend too much time managing these requests. Instead, teams should standardise how others submit work, and inbound work should live in backlogs that can be reviewed and prioritised asynchronously. For example:

- Technical writers are partly responsible for improving existing product documentation. People should submit feedback regarding these documents to the team via a standardised form (perhaps a feedback form embedded directly with each product document) that funnels requests into a team-wide backlog (*e.g.,* in JIRA or GitHub Issues).
- Sales engineers responsible for delivering technical demonstrations to customers could provide a calendar booking link that enables account executives to organise demos easily.
- Support engineers responsible for helping customer service staff with customer escalations might receive support tickets in help desk software.
- UX designers responsible for gathering customer feedback might receive leads for interviews in a team-wide backlog that can be prioritised and organised.

When you funnel requests into an asynchronous backlog, you remove the need to respond immediately to each new request. This gives you the freedom to tackle your backlog on your terms. You might run a monthly prioritisation session and give each team member a few weekly tasks from the top of the backlog. You might flag urgent requests for immediate response and group lower-priority requests into larger projects.

Tags: advice, startups, highlights, operations

# Fixing startup problems in the right place

When you build a startup, it can feel like you're constantly solving new operational problems within your teams. Many startup leaders address these growing pains as they arise without thinking about what the root cause of any given problem can tell us about *where* we should solve it. By solving each problem in the right place, you can build a simpler and more operationally effective business.

Startups operate as a series of interconnected value chains, all of which start with product. For example, the sales value chain starts with product (*i.e.,* chosen market, chosen problem, and chosen solution with all its implementation details), moves onto marketing (*i.e.,* messaging, brand, digital, and the resulting quality and volume of the top of funnel), and finishes with sales (*i.e.,* deal prioritisation, sales pitch, and the resulting won and lost opportunities). 

Every layer of the sales value chain is constantly working to compensate for the shortcomings of the previous layers. Through excellent marketing (notably messaging and targeting), even an imperfect product targeting a small market can be easy to sell. Through enormous sales grit, an inadequate product with poor marketing can grow, though it is incredibly challenging. Startups that build a **perfect solution** to a **huge problem** for a **massive market** don't need to do much marketing or sales.

Similarly, the customer experience value chain starts with product (*i.e.,* chosen market, chosen problem, and chosen solution with all its features, usability, and technical debt), moves onto reactive customer support (*i.e.,* customer support tickets), and finishes with customer success (i.e., account management of escalated customer issues, churn operations, activation of new customers). It is also, of course, downstream of the sales value chain.

Just like with sales, every layer of the customer experience value chain is constantly working to compensate for the shortcomings of the previous layers. A high-performing support team can compensate for a difficult-to-use product and make life very easy for customer success by making customers happy before customer success gets to them. Great account management from customer success can result in low customer churn, even if a support team is struggling. A product with no bugs and a fantastic UI that is targeted at a market that is technical might not even need a support team.

The takeaway here is that most of the growing pains experienced by startups can be solved in more than one place. For example: a startup that is struggling with customer retention due to a massive support backlog could fix this problem at almost every stage of the value chain. This startup could:

- Hire more (or better experienced) customer success people to better manage customer complaints and convince customers to stick around.
- Hire more support team members to reduce the support backlog, reducing the need for as many (or as experienced) customer success managers to deflect churn requests.
- Change focus (or invest more) in product development to improve the usability or reliability of the product, reducing the need for as many customer support and customer success resources.
- Prioritise leads differently in sales to target customers who have in-house technical resources, reducing the need for customer support without significantly changing the product.
- Target a different market segment in marketing to target businesses who are better suited to the current product.

The best way to solve a big problem is at the top of the value chain. If you can adjust your targeting in marketing to remove a problem in customer support without slowing down the growth of your business, you will build a business that is stronger and easier to operate. Every problem you solve by hiring new resources or implementing new processes makes your business more complex and difficult to operate.

Of course, not every problem can or should be solved this way. Small problems are perfectly fine to fix deeper in the value chain. Additionally, changes at the top of the value chain (*i.e.,* marketing or product) usually take a long time. So, sometimes it is easier to fix something in support or success temporarily while you change course at the product or marketing level. The critical takeaway is not to solve everything at the top-level, but rather to always consider your options and make the conscious decision of where each issue should be rectified, rather than solving problems on autopilot within each individual department.

Tags: advice, startups, strategy

# Structuring your SaaS P&L

As your startup matures, there are several SaaS-specific business metrics that you will want to track to improve your decision-making, ascertain the health of your business, and benchmark yourself against other SaaS startups. Structuring your finances (specifically your profit and loss statement) in a SaaS-friendly way can make it very easy to track these metrics.

## Sanitise your recurring revenue

Several of the most critical SaaS metrics (and your valuation) heavily depend on your recurring revenue (*i.e.,* ARR or MRR). So, having a sanitised and accurate view of your recurring revenue is critical. On your P&L, make sure your revenue is split into multiple lines so that it is easy to differentiate between the different types of revenue you collect, and your recurring revenue does not include any other revenue types like professional services. This is equally as important for transactional SaaS businesses.

![Make sure recurring revenue occupies it's own revenue line in your P&L](https://static.fastertimes.cloud/post-attachments/pandl/pandl-revenue.svg)

## Align cost centres to key SaaS metrics

In most businesses, expenses are allocated to functional cost centres, meaning each department will have its own expense line.

![Some of the mistakes that startups make when grouping costs in their P&L](https://static.fastertimes.cloud/post-attachments/pandl/pandl-costs-before.svg)

While this makes sense for most businesses, it can be tough to calculate specific SaaS metrics. The fact that many departments have responsibilities that impact multiple SaaS metrics causes this difficulty. For this reason, I recommend adopting the following expense categories (more granular is fine, though, as long as they can sum up to these categories):

- **Recurring Revenue COGS** or *the cost of your recurring revenue*. This tells you how much it costs you to provide your software to your customers. This is the total of your cost to support your customers (customer support team salaries, tools, and other expenses) and the cost of any infrastructure, hosting and third-party licenses for your software. 
- **Customer/Revenue Acquisition Costs** or *the cost of acquiring new customers/revenue*. This tells you how much you're spending on growing the business, allows you to calculate key metrics like *CAC* and *CAC Payback*, and typically includes sales and marketing salaries and expenses (e.g., events, tooling).
- **Product Development Costs** or *the cost of expanding your product through software development*. This tells you how much it costs to improve your product and includes most of your product/engineering team salaries and the other expenses associated with your product development efforts (such as tools).
- **Professional Services Costs** or *the cost of providing billable professional services to your customers*. If you offer billable professional services to your customers, you should have a revenue and an expense category for professional services. These expenses typically include the salaries of your professional services team and any tools they use.

![The expense groupings I recommend you use in your P&L](https://static.fastertimes.cloud/post-attachments/pandl/pandl-costs-after.svg)

The reason these buckets are more valuable than department-specific expense lines are:

- Your product and engineering departmental costs don't exclusively fit into **Product Development Costs** because hosting, infrastructure, and maintenance costs belong in the **Recurring Revenue COGS** bucket.
- Functions like customer success, who work to both grow and retain revenue, typically fit in both the **Customer/Revenue Acquisition Costs** and **Recurring Revenue COGS** buckets.
- **Customer/Revenue Acquisition Costs** needs to include anything related to acquiring new revenue/customers which for many companies can include cross-company expenses that might not fall into the budgets for your sales and marketing teams by default.

Finally, let's talk about the SaaS financial metrics you should track. These won't live in your P&L, but you will calculate them using the above revenue and expense categories. Many more metrics matter [and I've previously outlined an enormous list in my 101 on the SaaS business model](https://fastertim.es/post/what-is-saas). But, the foundational financial metrics that you need are:

- **Recurring Revenue Gross Margin** → The profitability of your recurring revenue. This is your Recurring Revenue COGS divided by your Recurring Revenue (*e.g.,* MRR COGS ÷ MRR or ARR COGS ÷ ARR).
- **Cost to Acquire a Customer** or CAC → The cost for acquiring each new customer. This is your **Customer/Revenue Acquisition Costs** for a given period divided by the number of new customers gained during that same period.
- **Cost of New ARR** → For every dollar you spend on acquisition, how much MRR do you earn? This tells you how efficient your sales and marketing efforts are. You calculate this by dividing your Sales & Marketing Costs by your New MRR (Sales & Marketing Costs ÷ New MRR). 
- **CAC Payback Period** → You use this to benchmark the long-term sustainability of the business and its sales model. It estimates the number of months it takes for the SaaS provider to recoup the cost of acquiring the average customer and is calculated by comparing your *CAC* (*Cost to Acquire a Customer*) to your *ARPA* (*Average Revenue per Account*), while factoring in your *Recurring Revenue Gross Margin* (CAC ÷ (ARR ARPA × ARR Gross Margin) × 12).
- **R&D:Recurring Revenue Ratio** → This metric tells you how much you spend on R&D in comparison to your recurring and is a useful for benchmarking R&D spend against other SaaS businesses. You calculate it by dividing your R&D Spend by your recurring revenue (e.g., Monthly R&D Spend ÷ MRR or Annual R&D Spend ÷ ARR).

[Learn more about the metrics that might matter to your startup](https://fastertim.es/post/what-is-saas).

Tags: advice, startups, operations

# Getting started with partnerships

Technology and professional services partnerships are crucial to the success of many B2B SaaS startups. But, many startup leaders don't appreciate how valuable partnerships can be, and it isn't easy to know where to start.

Let's explore the different types of partnerships that B2B software startups are typically engaged in and how partnerships can help you grow your startup.

## Professional services partnerships

If you're selling software to a business, chances are someone is selling professional services to that business (*e.g.,* accountants, web designers, marketing agencies, ERP consultants). If your product can help an agency to solve a problem for its clients, a partnership could be a mutually beneficial opportunity. Many successful B2B SaaS businesses have accelerated their growth and improved the customer experience for their products by partnering with professional services agencies within their ecosystem (*e.g.,* ecommerce web design agencies recommend Shopify, which has helped to drive their growth). 

The simplest form for these relationships is one where agencies refer prospects to you because they trust that you can solve a problem commonly experienced by their customers. For example, an accountant that focuses on businesses in the events industry might frequently recommend specific expense tracking software to their clients because they know this is a common challenge within their customer base. These types of partners are commonly called referral partners. Your relationship with them could be informal (*i.e.,* if your product makes their lives so much easier that they don't need any incentive to recommend it) or driven by incentives (*e.g.,* one-time or ongoing commissions on revenue generated from successful referrals). Note that while not all referral programs target professional services agencies (*e.g.,* they may target customers or other individuals/businesses), this seems to be the most fruitful model in B2B SaaS.

Many software products require some configuration for prospects to adopt and use, and this configuration is often completed via in-house onboarding/activation professional services. This need forms the basis for another type of agency partnership: one where the partner agency fulfils services related to your product for your customers. The relationship here is inverted because the agency solves a problem for you (*i.e.,* onboarding). As many startups find product-market fit, they start to grow so quickly that they cannot scale their in-house onboarding and professional services teams quickly enough to keep up. This is where outsourcing this work to partner agencies can provide a more scalable model for onboarding services (assuming these services cannot be easily eliminated through product innovation). The benefit for partner agencies is that this work comes with meagre customer acquisition costs because instead of conducting their own sales and marketing to find new clients, they receive leads from you (leads that you've already spent money to acquire).

Lastly, many products that target large businesses will find they frequently come by prospects who want some very specific customisations or additional functionality. Sometimes, these requests are worth considering because they will benefit the broader customer base. Otherwise, they may be so precise that they are significant distractions from your core focus. By partnering with software development agencies (and having good APIs) you can make it possible for very large customers to solve their own problems with your product as a platform.

## Technology/integration partnerships

Technology partnerships are partnerships centred around the integration of external products or systems. The beauty of these partnerships is that they allow you to remain focused on solving the problem at the core of your product mission. They do this by allowing your customers to gracefully overcome the current shortcomings of your products' features by pairing your product with another. For example, as a digital advertising product, you may recognise that your customers want the ability to retarget their prospects via email. You could build this functionality directly or simply integrate with the major email marketing platforms already being used by your customers. By integrating and partnering, you can remain focused for longer, and reserve the right to expand the scope of your product in the future when it makes more sense. These integrations can also serve as a channel for new customer acquisition. Chances are if your partnership and integration with a third party solves a problem for your customers, it probably solves a problem for your partner's customers. Your new partner might be willing to market your solution to their customers if you solve a big enough problem for them that the integration could help them to grow or retain customers.

The most common type of integration partnership is *outbound integrations*. These partners are businesses whose services you integrate with, so you build, own, and maintain the technology behind the integration. Typically, these integrations extend the capability of your product (*e.g.,* as a payment processor, you may not want to build out your own tax engine, so you partner and integrate with a business and product that is focused on this), or better fit into your ecosystem (*e.g.,* when building a company targeting ecommerce merchants, it may be required to integrate with the various accounting systems used by these merchants).

The other type of integration is an *inbound integration*. These partners are businesses whose services integrate with you. The big difference here is that the partner builds, owns, and maintains the technology behind the integration. Whoever has the least leverage in the relationship (*i.e.,* usually but not always the smallest company) typically ends up having to build and own the integration, so in the early days of your startup, you'll have very few inbound integrations. Over time, however, as you become more dominant in your market and occupy a more critical portion of the toolkit of your customers, you will find that other businesses are willing to integrate with you.

Inbound integrations are cheap — because the partner builds, owns, and maintains the technology behind the integration, you only need to build and maintain your APIs. This incredibly scalable model is how companies like Apple, Google, Shopify, and others have become platforms. Inbound is not always better, though. While you can only build so many outbound integrations (because they require much more development effort to build and maintain), this approach gives you much more control over the functionality and reliability of the integration. Many integrations are so crucial to your product and business model that they justify the in-house development and maintenance costs.

## Getting started with partnerships

Partnerships should play a more prominent role in your startup strategy if:

- You feel inundated with diverse feature requests that seem to pull you in different directions.
- Large prospective customers require bespoke functionality in order to adopt your product.
- You are too reliant on digital marketing or outbound sales and feel the need to diversify your lead channels.
- You operate within an existing ecosystem of software and services that you would benefit from fitting better into.
- Your product solves (or causes) problems for existing software or services companies.
- Your product is easy enough to sell that a network of referral partners could drive its growth.

To determine who to partner with, consider:

- When reviewing feature requests, always ask yourself whether this could be better solved by partnering with another company.
	- Is there already a highly-focused, best-in-class SaaS solution for this feature that you could integrate with?
	- Are there professional services agencies who can help with this by building something for your customers?
	- Does temporarily outsourcing this capability to someone else cost you anything in the future?
	- What types of agencies do the other software companies in your ecosystem typically partner with?
- Ask your customers about the professional services rely on. Also consider services that they required when they were first getting started. Are there opportunities to better fit into this ecosystem of professional services? Would there be mutual benefits to working more closely with the agencies mentioned by your customers? 
- Ask your customers what other software products they use. Are they solving problems potentially faced by other customers? Would a partnership or integration with these products round out your offer and help you to grow faster?

Lastly, there are technical considerations for any software company that may eventually depend on partnerships:

- **Is your product currently serviceable in a way that would work for third parties?** Does your internal team currently depend too heavily on privileged access or tools that you could not offer to partners? Is your documentation good enough for someone external to your team to learn to service your product.
- **Have you got APIs that will enable professional services agencies to extend your product for individual customers?** Especially in enterprise, you will hear from prospects who need customisations that you cannot justify building in-house. APIs can enable these prospects to have your agency partners build these custom features themselves.
- **Have you got APIs that will enable future inbound integrations?** Even if partners have little appetite to commit to integrations, this is a well you must dig before you need it. Good APIs will ease the transition from outbound to inbound partner integrations.

Tags: advice, startups, strategy

# Simple capacity planning for startups

As your startup grows, your team will get busier. More customers means more onboarding tasks, professional services projects, and support tickets. While this is a great problem to have, many startup leaders find it difficult to determine how many people they need in each team. Fortunately, some simple capacity modelling can simplify this process.

Today, we're going to build a very simple capacity model for a customer support team. The principles of this process are applicable to any team that is made up of a number of staff who share very similar tasks and whose work is relatively focused. It should be easy for you to adapt this exercise for professional services, customer success, sales, account management, and recruiting teams. It may not work as well for marketing, product development or management/executive roles.

The first step of capacity planning is usually to tie our workload to the size of our customer base. This is important as it allows us to estimate our future workload based on customer growth. To do this for our imaginary support team, we need to know how many support tickets are coming in each month, how many customers we have, and how these numbers relate to each other:

1. Record how many inbound support tickets were raised for each recent month.
2. Record how many customers we had in each recent month.
3. Calculate the average number of tickets raised per customer by dividing the number of support tickets raised each month by the number of customers for each month.

![](https://static.fastertimes.cloud/post-attachments/capacity-planning-diagrams/capacity-planning-step-1.svg)

Now that we know how our workload relates to the size of our customer base, we can use our sales targets or projections to estimate how our workload will increase over time.

1. Add the number of expected customers, based on the sales targets or projections for your startup, to the model.
2. Estimate the number of support tickets you will receive in the future by multiplying the average number of tickets raised per customer by your expected future customer count.

![Projected customers might come from your sales targets, while inbound tickets and tickets per customer can be estimated based
on historical data.](https://static.fastertimes.cloud/post-attachments/capacity-planning-diagrams/capacity-planning-step-2.svg)

Let's form an understanding of how we're handling our current workload. 

1. Add to your model the number of support tickets we are resolving each month.
2. Use the historic median or average to estimate how many you expect to complete in future months.
3. Calculate the gap (_i.e.,_ the delta) between the work that is coming in and the work that is being completed. To do this, simply subtract the number of support tickets your team is resolving from the number that is coming in. You might want to also calculate this as a percentage.

![Ticket delta is simply inbound tickets less the number you resolved
for that month. It tells us it we're over capacity.](https://static.fastertimes.cloud/post-attachments/capacity-planning-diagrams/capacity-planning-step-3.svg)

Now, we already have a very simple model which tells if we are over capacity or not. Next, we will consider the current size of our team to estimate how many individuals we'll need in the future.

1. Add the current number of customer support employees for each month.
2. Divide the number of support tickets we are resolving each month by the number of customer support employees for that same month. This tells us how many support tickets the average employee can complete. In the example, I instead use the median.
3. Multiply the support ticket delta (_i.e.,_ the gap between the work that is coming in and the work that is being completed) by the average number of support tickets per employee. This tells us how over (or under) capacity we are in terms of customer support employees.
4. Apply this same logic to future months to get an idea of how many people you could need in the future.

![By dividing the number of tickets we're failing to complete each month (i.e., the ticket delta) by the number of tickets each employee can
typically solve, we can estimate how many more people we need to handle our workload today or in the future.](https://static.fastertimes.cloud/post-attachments/capacity-planning-diagrams/capacity-planning-step-4.svg)

For many teams, what we have so far is enough to roughly predict how many people we should be hiring each month to keep up with our momentum in sales. One shortcoming, though, is that by relying on historic averages, our model assumes that we are happy with the efficiency or productivity of our team. This can result in inefficient team growth. Generally, the best way to grow a team is to not only hire new individuals but to also optimise the ways of working and enhance the capability of the existing team.

A simple way to consider productivity is to breakdown our current performance (_i.e.,_ the number of support tickets we are completing each month) by employee. This will provide some basic insights into how the team is performing, especially for larger teams.

Add to the model each customer support employee and the number of support tickets they are resolving each month.

![Looking at productivity data on a per-employee basis can help to identify opportunities for improved efficiency.](https://static.fastertimes.cloud/post-attachments/capacity-planning-diagrams/capacity-planning-step-5.svg)

Usually, clear patterns will be immediately apparent. You might notice that some individuals are over performers while others are clearly lagging behind. This simple information is valuable for optimising your team. Investigate what sets apart the over and under performers. Over performers might be employing specific tactics or ways of working that can be adopted by the rest of the team. They may have specific experience or skills that you can hire for in the future. Under performers could have specific skill gaps that you can improve through training.

As your team grows, you will want to forecast your resourcing requirements based on high-performing individuals, rather than the average for the whole team. This will ensure that you couple any budget increases with efficiency improvements (_e.g.,_ training, improved ways of working, better tools, better hiring).

1. Recalculate your tickets per employee metric to only look at the top performers in your team.
2. Your capacity gap should shrink. In our example, improving the productivity of under performers will allow us to handle our workload with two fewer employees.

![Narrowing your capacity calculations to only include acceptably peforming employees will allow you to balance productivity improvements and budget expansion.](https://static.fastertimes.cloud/post-attachments/capacity-planning-diagrams/capacity-planning-step-6.svg)

Tags: advice, startups, operations, people

# DevOps is more important than product management for startups

Building software can seem deceptively easy in the early days of a startup because small teams can get by without much process and structure. Communication, strategic alignment and collaboration between engineers can be effortless when you've only got a few people. As you grow, though, things get complicated. Strategy becomes difficult due to competing priorities, so you adopt prioritisation processes. Collaboration between engineers becomes onerous, so you split your team into smaller teams. New features fail to meet customer needs, so you invest in more upfront feature scoping. Usually, much of this becomes the responsibility of your first product manager. As crucial as product managers are to software companies, I think DevOps is more important, and you should invest in it first when facing these issues.

DevOps is the practice of operationalising how you deliver software through automation, process and instrumentation/analytics. Key aspects of DevOps include:

- Automated testing. Instead of manually testing the features of your product before every release, you can write tests in code and run them during the development process. With automation, you can mostly eliminate the burden of testing from the release process.
- Automated releases/continuous integration. Instead of manually compiling and deploying new code on a weekly, monthly, quarterly or irregular basis, you can develop automation that will deploy code to your customers in real-time.
- Product analytics and platform observability. You can measure your product's performance in real-time through application logging and integration with analytics platforms. This data can then influence how you make decisions. For example, application logging can reveal bugs and platform performance issues before customers discover and report them. Similarly, product analytics tell you how customers use your product, influencing product prioritisation. 
- Feature toggles enable your engineers to choose who can access individual features and product changes without delaying the integration of new code into your product. Using toggles means pushing new code out with automated releases but hiding new features until they are ready, enabling easy early adopter or A/B testing.

In aggregate, the foundations above enable tight feedback loops, which empower teams to make better decisions, move faster, and deliver tangible outcomes for the business. Before DevOps, you need to manually test, manually release, manually survey customers and wait for bug reports before you know if the feature you built solves the intended problem and doesn't introduce new issues. After adopting DevOps, the time it takes to learn from previous decisions will reduce radically. You can move fast, easily pivot, and quickly learn how to make better decisions. In short, excellent DevOps practices solve many of the same problems that product management intends to solve. These technical foundations mean many teams won't need a product manager urgently because engineers and designers are empowered to build, measure, and learn independently. Additionally, teams that still choose to work with a product manager won't need micromanagement — they will retain much more autonomy than is otherwise possible without DevOps.

Product managers should embrace DevOps because it will help them to make better decisions, move more quickly, and operate from a higher vantage point (potentially overseeing multiple teams). A product manager empowered by continuous integration, automated testing, and product analytics can confidently encourage their team to move quickly without fear of failure. These operations reduce the damage potential of suboptimal decisions and implementation mistakes. DevOps implements the build, measure, and learn loop, making it possible to innovate through experimentation.

Both DevOps and product management seek to solve the following problems:

- Return on investment, impact of work, and outcome-centricity. Product management solves this by defining problems formally, guiding solution selection, modelling expected outcomes and specifying solutions. DevOps solves this problem by making it easy for engineers to ship minimum-viable products, develop iteratively, and measure the effectiveness of their work.
- Prioritisation. Product management solves this problem through centralised decision-making and stakeholder engagement. DevOps solves this problem by aligning teams to measurable outcomes and enabling rapid experimentation.
- Quality assurance. Product management solves this problem through oversight, manual test coordination and user testing. DevOps solves this problem with automated tests, feature toggles and continuous integration (which allows bug fixes to be deployed rapidly).
- Stakeholder management. Product managers solve this problem through meetings and outbound communication with internal and external stakeholders. DevOps addresses this with automated release notes/changelogs.
- Technical documentation. Product management prioritises and produces product documentation, while DevOps solves this through self-documenting code.

As you can see, you can solve many problems with either more product management or DevOps. As most companies scale, they will eventually adopt product management and DevOps. DevOps may be the best initial approach because it will keep engineers empowered to own the outcomes of their work for longer and will double as a fantastic foundation for future product management.

Tags: advice, startups, operations, technology

# How to recruit the right skills for your team

Building a team that can get the job done is the primary role of all leaders and founders. While this may include strategy and operations work, it all starts with recruiting talent. Great talent can always achieve more with less process or strategic clarity than employees who are not well suited to the task, so everything a leader does is secondary to recruiting. Many leaders struggle to determine what skills or experience are necessary for specific roles or teams because it is challenging to find candidates who tick every box. I believe the best way to build high-performing teams is to recruit a patchwork of skills and experience.

Candidates generally fit into these high-level categories:

* Business model experience. These candidates have worked at companies with similar business models (_e.g.,_ B2B SaaS), so they strongly understand how companies like yours operate.
* Technical experience. These candidates have worked with the technologies used by your company. They bring technical expertise that can level up your company.
* Industry experience. These candidates know the market you are targeting. They deeply understand your customers, partners and competitors.

For example, when hiring a product manager for a B2B SaaS product that targets the hospitality industry, the experience to look for might look like this:

* A candidate with business model experience has previously worked in a B2B SaaS company. They understand how these companies are typically structured and how they operate. This understanding is essential for product managers because building software products is very different from hardware, and candidates who haven't worked in product companies might not have the required operational experience. For example, people who've only worked in professional services may be better with project management rather than product management. When hiring product managers, it's generally safe to consider this a must-have.
* Technical expertise for product managers is broad. It includes their experience with the specialised practice of product management and their experience with specific technologies. Relevant technologies include productivity tools (_e.g.,_ JIRA, Confluence), analysis technologies (_e.g.,_ SQL, Excel, Salesforce) and the technical stack for your product (_e.g.,_ iOS, web apps, Ruby on Rails, Jamstack).
* Industry experience in this scenario would be the hospitality industry. This experience usually means the candidate has worked for a competitor, customer, partner, or prospect. A product manager with industry experience will find it easy to understand your customers, their needs, and the market in which you operate.

The same company hiring a customer success manager would look like this:

* A customer success candidate who has previously worked in a B2B SaaS company should understand how customer success typically works in these businesses. They've probably done quarterly business reviews before. They know how to ask a customer for a testimonial or case study. They know how to work with other teams to achieve customer results.
* Technical expertise for this role usually means experience with CRM software and other customer success tools. For some companies, it may also extend into their ability to use and solve problems with your product (candidates internally promoted from customer support roles often meet this profile). It can be valuable for customer success managers to be able to solve some problems themselves.
* Industry experience is precious in customer-facing roles like customer success because it can take years to acquire a deep understanding of your customer's problems. Many companies achieve this by hiring employees from their customers' businesses.

In both of these examples, it is easy to imagine how a candidate who fits these criteria would be the perfect recruit. Unfortunately, while some candidates may fit into multiple categories, finding people who fit into all three can be challenging. Additionally, broadly experienced candidates rarely go deep into any specific area, which may water down their effectiveness. This challenge is why the best way to recruit is to build a team of individuals with complementary experience that collectively have broad experience. Instead of looking for individual candidates with all these traits, build a team with combined expertise in these areas.

In the early days of startup building, one or two individuals will power most functions. This resource constraint can make building a solid patchwork of experience and skills challenging, so it is essential to consider what type of experience is most important for your team. For example:

* Unique business models might demand a team with experience in similar businesses.
* Some technical stacks can be too complex for new candidates to learn from scratch, so you might need to prioritise specialised experience.
* Some markets are less approachable than others. The average person has a lot more exposure to retail than to business banking or biotech, so industry experience also varies in importance.

By being intentional about what types of experience are most important for each role, and considering team-wide capability rather than individual capability, leaders and founders can create powerful teams and nail the first and most crucial step of startup building.

Tags: advice, startups, people

# Delegate responsibilities to systems, not tasks to people

Most leaders think of delegation as shifting tasks or responsibilities from one individual to another (_e.g.,_ "I don't have time to do something, so I'm going to give it to one of my tech leads"). This attitude towards delegation entrenches single points of failure and does little towards building robust systems and ways of working for your team. The ideal way to approach delegation is to delegate responsibilities (not tasks) to rituals or ways of working rather than specific people.

To delegate to a ritual is to **integrate a job into the ways of working for a team**, as opposed to shifting a responsibility to an individual. For example:

- **Code reviews.** Instead of having a single person conduct code reviews, implement a ritual whereby engineers peer review each others' code. You could add a column to your scrum/kanban board to reflect this.
- **Drafting initiatives.** Rather than having product managers draft an initiative brief for new opportunities, create a standardised format for these and encourage all stakeholders and team members to draft initiatives.
- **Call monitoring.** Peers can often monitor and provide feedback on sales, support, and customer success calls just as effectively as managers can.
- **Support triage.** Triage for support tickets can be a rotating responsibility that changes hands each day or week instead of being the responsibility of a specific team member.

By integrating responsibilities into your team's work, you can create an incredibly robust and versatile team by eliminating single points of failure. Suppose only one person in your team tends to a specific task (_e.g.,_ only tech leads carry out code reviews). In that case, you are creating operational risk in your business because momentum will slow down or even halt should that person go on leave or exit the business. Teams should be able to operate without managers and key people, who should be more focused on evolving how the team operates than completing critical tasks themselves.

Shared responsibilities are also natural ways for individuals to become more capable over time. By encouraging all team members to contribute to jobs traditionally owned by management (_e.g.,_ quality control of code or customer interactions), you can more passively train your team members. This is great for the career development of individuals and the growth of the business. Additionally, the ownership of these tasks encourages individual contributors to think and behave more like leaders, which leads to better outcomes for the team thanks to improved creativity and ownership.

One of the risks of this type of delegation is that managers tend to overload existing teams with new streams of work that should instead sit with a new group. Sometimes, shared responsibilities can be excessively burdensome on the team and reduce their ability to focus on their core responsibilities. Teams and individuals work best when working towards a single goal; each of their responsibilities contributes towards this and comes from the same backlog of work. When teams start to juggle multiple goals, especially if these goals require very different approaches, they will usually fail at one or both. For example, individual salespeople owning outbound and inbound sales will usually fail because these functions address very different problems in different ways. Similarly, front-end developers who also own user experience design will often struggle because it is difficult to manage two backlogs of work at once (_i.e.,_ things that must be designed and things that must be developed).

Here are some other scenarios where responsibilities should be split into new teams rather than shared by a single team:

- Tasks that are excessive in volume and come from a different backlog are often best owned by a specific individual or team to enable each team to remain focused.
- Tasks that take a long time to complete can become long-term distractions for individuals primarily focused elsewhere. These tasks are particularly ill-suited for round-robin style processes because contributors will either need to hand them over before they are completed or be bogged down by them for a long time. For example, having email support staff rotate the responsibility of triaging new tickets makes sense because each ticket only takes a few minutes to review and assign to a queue. When the employee owning this is done for the day, they won't need to keep any partially completed tasks, nor will they have to hand anything over to the next person. In contrast, rotating support team members through the completion of high-priority tickets for enterprise customers might not make sense because these tickets may take a long time to investigate and resolve, meaning someone with a long-term focus on enterprise support tickets would be best positioned to solve this problem.

Many leaders view their responsibilities as a list of leadership and management tasks they need to complete. This mindset ignores that the best way for a team to get most things done is through shared ownership and leadership. Managers should ensure the vital work gets done, but they should be open-minded about who does it. Where possible, it is better to delegate (to a shared responsibility rather than an individual) than do it yourself because this builds a repeatable system that depends on a team rather than any individual. This is the best way for leaders to create value that will outlast their tenure at the company.

Tags: advice, startups, people

# Cut old habits to maintain momentum and urgency

Healthy habits are critical for all successful product development teams. Much of the content you'll read from product pundits (like yours truly) covers the variety of (sometimes contradictory) habits we think you should adopt. I think the importance of breaking (and avoiding new) bad habits is under appreciated. This effort is much more important than forming healthy habits because, without the bad getting in the way, you can make the rest up with common sense and a dedication to self-improvement. I believe that, while adopting good routines and practices is valuable,  high-performing teams succeed because they successfully avoid settling into a rhythm, always making decisions with intentionality rather than delegating to autopilot.

First, let's establish why habits can be positive: by adopting a routine, you are standardising how you deal with a problem. This can be a great way to break down something big or to simplify the decision-making required to get something done. 

For example:

- Retailers adopt end-of-day/shift reporting routines in the short term to simplify their business reporting duties in the long term. By getting your finances in order at the end of each day, you are breaking down the mammoth end-of-month or end-of-year tasks that come later.
- Airlines centralise decision-making through the adoption of checklists for personnel. Without routines, each pilot and crew member across all fleets would have to devise their own way of working. With established practices, individuals don't need to know the best way to get something done that has already been investigated and decided: they simply need to execute the steps they are given. 
- Individuals exercise daily to remove the "when should I exercise?" decision from the health and fitness equation.

A recurring theme in the examples above is that when something becomes a habit, it becomes almost automatic. Completing tasks within a routine comes with much less cognitive load than completing a job outside of a routine. This is great when you just need to get something done without overthinking whether you should do it or how you should do it. Unfortunately, the most critical decisions faced by product and engineering leaders are whether you should do something and how you should do it. This is where turning everything into a business-as-usual, standardised, nothing-to-see-here routine starts to work against you.

In the world of building software, there are a lot of decisions that you never want to make while cruising on autopilot. This is where routines can become the enemy because teams make fewer decisions with intentionality by relying too much on established habits. In scrum, for example, teams tend to do great with sprint goals for the first few iterations. When planning their work for the next two weeks, they set a clear goal and only take on work that contributes to it. The problem is, after a few sprints and as the backlog grows, sprint planning becomes too ritualised, and many teams fall into the habit of making decisions about what to work on next based purely on what is at the top of their backlog that can fit into two weeks. Sprint goals are now drafted as summaries of what made it into the sprint, rather than the contents of the sprint being based on the predefined goal. What was a productive ritual (sprint planning) has turned into an unproductive one: this team is no longer goal orientated and is unlikely to achieve great outcomes.

Here's the rub: every productive habit is at risk of eventually becoming unproductive. This is why teams should entirely avoid the autopilot problem through a radical dedication to intentional decision-making and an allergic resistance to unnecessary (or no longer necessary) processes. Retrospectives are the best preventative for bad habits, but not all retrospectives are created equal. To succeed, someone who is truly dedicated to having frank conversations about how things are going must facilitate them. Self-accountability is the best form of accountability for a team; anything the team can change or can have changed for them should be discussed. This is where teams should scrutinise their rituals and identify bad habits they are falling into.

Here are some more tips for avoiding the autopilot problem:

- Where possible, adopt dynamic rather than static rituals. For example, many teams break up their work into two-week sprints. This arbitrary cadence is precisely the type of thing that pushes teams to settle into autopilot eventually. Instead, define sprint goals first, and set the sprint length based on how long the team needs to achieve the goal.
	- During long sprints, teams lose their sense of urgency quickly. I recommend only ever running one-week or two-week long sprints. 
	- Be biased towards shorter sprints. If a goal will take two weeks to achieve, try two one-week sprints. If a goal will take three weeks, start with a one-week sprint, followed by a two-week sprint. This allows you to revisit the plan just a week after getting started.
- Set time-based goals beyond individual sprints. While sprint goals are naturally time-boxed due to the set length of a sprint, many teams do not set deadlines for initiatives that will take longer than a single sprint. I think that this is essential for the intentional decision-making that we want. So, when picking up an initiative, teams should set their own deadline for when they want to have it completed.
	- To explain this further, one critical component of good product decision-making is finding alignment between the value in solving a problem and the effort required for the chosen solution (_i.e.,_ return on investment). As a team, you want to make sure that the effort you're investing into solutions is proportionate to the size of the respective problems, otherwise you won't get return on invested effort. One way for teams to manage this is by setting deadlines. Ask yourself: "How much time are we willing to invest in solving this problem? How much would we be delighted with? How much would be acceptable? How much would be unacceptable?" Stick to these deadlines — sometimes it is best to move onto something new if your current solution is taking much more effort to implement than you originally expected.
	- When I talk about deadlines, I'm talking about deadlines that are internal to and owned by the team, not imposed on them externally. These are a tool for self-accountability.
- Avoid abstractions when assessing progress. Many teams work in one tool (_e.g.,_ JIRA) but communicate through something entirely differently (_e.g.,_ PowerPoint, Confluence). While this is OK when trying to distill your message for others, decision-makers should try to be as connected to the work as possible. During team rituals, look at the board or task list directly. Pay attention to where progress is being made, and where it is not.

Tags: advice, startups, operations

# A simple framework for employee onboarding

Coaching and 1:1 contact works better than structure and process for early-stage startups. This means managers and peers should spend a lot of time with new hires to guide them through their onboarding.  As you grow it will become essential to standardise employee onboarding with standard operating procedures, especially for common roles (_e.g.,_ customer service, sales, engineers). But, in the early days, this can probably wait.

Design all roles to have specific goals and responsibilities. Goals tell employees what success looks like, and responsibilities give them a clear idea of what they should be doing. Goals are more important than responsibilities because innovative employees might achieve their goals in creative ways that redefine their responsibilities.  While you can do this through simple job descriptions, I recommend adopting role playbooks (which you can read more about here).

Set very clear expectations for what new employees should achieve in their first thirty, sixty or ninety days. For KPI-driven roles like sales and support, these could be based on the success measures your new employee will eventually be held to (_e.g.,_ we expect support agents to be solving at least 10 cases per day within three months of starting). For unique roles like management they could be based on deliverables (_e.g.,_ deliver an analysis of the current state of the partner channel and outline opportunities and obstacles for our goals). For positions that cover a wide range of responsibilities it can be helpful to instruct new starters to focus on just a subset of responsibilities for the first few months of employment (_e.g.,_ a marketing manager could focus on just social media and events for the first few months). Communicate these expectations during the hiring process and standardise/define these success measures in your role playbooks. This makes conversations around performance with new starters much more productive and straightforward.

It's critical to keep new employees focused. In startups it is often tempting to give additional responsibilities to employees, especially high-performers. This not only solves problems, it provides career development opportunities. Doing this too early can seriously sabotage new employees, though. By getting caught up on new responsibilities, new employees often fail at their core role, depriving them of the opportunity to prove themselves in the role they were hired for. A simple rule of thumb is to never broaden the scope of someones role until they have first demonstrated success in their core role (as per the criteria in the previous paragraph).

Tags: advice, startups, operations, people

# Improve your product by analysing the responsibilities of your users

Mapping out the goals and responsibilities of your users can be a great way to identify opportunities to solve problems for your market. This is useful if you want to pivot your product towards solving a more valuable core problem. It will also help you to expand the scope of your product to solve new problems in addition to your current area of focus when trying to differentiate your offering. This is best workshopped in a hands-on fashion with a sample of your existing customers and can be done easily with just a whiteboard.

To begin this process, spend some one-on-one time with each research participant to identify their various work-related responsibilities. To make this easier for users, I like to start with time-based headings/categorisation like _daily tasks_, _weekly tasks_, _monthly tasks_, etc. Include estimates for how much time each task typically takes. During this phase of the workshop, your job is to listen (and scribe) — the list does not need to be perfect, but it should be pretty extensive and honest.

![The responsibilities of an accountant in a SaaS business](https://static.fastertimes.cloud/post-attachments/jtbd-accountant-1.svg)

Next comes the collaborative analysis. With the user, start to dig into each task and identify their goal for this task. This is all about the desired outcome and needs to be solution-agnostic. For example, when walking the dog, your goal is not to take the dog for a walk, but rather to keep the dog healthy and happy (_i.e.,_ walking the dog is a solution, health and happiness is the desired outcome).  

![The goals of an accountant in a SaaS business](https://static.fastertimes.cloud/post-attachments/jtbd-accountant-2.svg)

Now that you have an exhaustive list of your users goals, you should be starting to get an idea of some of the problems you could be solving for them. This is when I like to do a little more analysis to look for goals that seem related to each other and are consuming a lot of time or causing a lot of pain for the user.  Call these areas out as themes and keep a record of how much time they are taking up in total.

![The challenges faced by an accountant in a SaaS business, grouped by common themes](https://static.fastertimes.cloud/post-attachments/jtbd-accountant-3.svg)

Your job now is to rinse and repeat this process with more research candidates to diversify the viewpoints you have received. For some products, all users play a consistent role within their respective organisations. For other products, diverse organisational roles with overlapping responsibilities will lead to more unique opportunities and edge-case results. After you've conducted a number of these workshops, you can bring the results together. What were the most consistent themes across all of the workshops? Did certain time-consuming goals standout as particularly frequently encountered? These prevalent problems to be solved could be your best opportunities to delight your users with future solutions.

Your eagerness to jump in and solve the user challenges identified through this exercise will vary. Mature companies may want to be highly confident in the return-on-investment for any major new initiative — if this sounds like you, I recommend validating these results with prospects within your market who don't currently use your product. This could include churned customers, businesses who have only recently entered your sales funnel, and previous lost sales opportunities. Early-stage startups, however, may have less access to data and instead prefer to move ahead with more urgency.

## Implementation details

- Participants should be active _users_ of your product, not managers who purchase your application but don't spend time using it first-hand.
- As the customer base for a startup grows, it becomes more representative of its target market. If your customer base is small, listening too much to existing customers rather than the broader market could lead you to develop features that are too niche to adequately monetise, which can increase your maintenance burden more than it increases your revenue. If your customer base is large, the insights gained from it could be one of your most valuable assets.
- As great as proactive research activities like this can be, the best startups capture insights throughout the customer journey and make decisions based on data from diverse sources. [Learn more about operationalising insights from customers](/post/customer-feedback-strategy).
- This exercise works best for B2B products and B2C products that aim to solve problems for users (to either make them more money, improve operational efficiency, or simply make their lives easier). Many B2C apps can be more data-driven, so are better off experimenting with new features through A/B testing.
- This exercise also works great for internal stakeholder users. For example, you could run this exercise if you want to build internal tooling and automation to help your internal teams to work more efficiently.
- Solutions to issues identified here don't always need to be product features — education, a change to ways of working, technology partnerships/integrations, and professional services are other options.
- This exercise is heavily derivative of [the Jobs to Be Done framework](https://hbr.org/2016/09/know-your-customers-jobs-to-be-done).

Tags: advice, startups, strategy

# How sales innovation can drive product-market fit

Sales model innovation is the most underrated challenge in conversations about product-market fit. Failing to experiment and innovate on the sales layer causes many startups to lose hope in markets, problems, and solutions with huge potential. Founders assume that because their solution isn't selling, it must be an inadequate solution, or the market and problem they've identified are not big enough. Many teams expect product innovation to solve the product-market fit problem single-handedly, so they abandon anything that isn't easy to sell, and burn their early-stage runway on product iterations. Often, some discipline and experimentation in the sales process could've successfully brought their early solutions to market. The problem with the typical framing of the product-market fit mental model is that it suggests that a startup will succeed so long as it finds a big problem and solves it. Unfortunately, it is rarely this simple. I encourage startups to adopt a disciplined, data-driven approach to marketing and sales to expand their criteria for product-market fit to consider the suitability of the sales model to the market and the product.

Each stage of the sales funnel validates something different about your product and market, so gathering feedback from the sales process is the most critical research a startup can conduct. Below is an example of how I look at early-stage sales funnels:

-  **Market-qualified leads.** These are leads confirmed to be from the market you are targeting. 
- **Problem-qualified leads.** These leads are confirmed to be experiencing the problem you're trying to solve and are willing to pay for a solution.
- **Solution-qualified leads.** These are leads that, based on sales conversations, are well-suited to the solution you're building.
- **Converted leads.** These are leads that you have successfully converted into customers.

_These criteria for these funnel stages should be easy to map onto all sales funnels, from traditional SaaS to enterprise and product-led growth (using data collection)._

As measured by the funnel above, outcomes tell teams how suitable their market, product, and sales model are, enabling product and sales model innovation. For example:

- A lack of **market-qualified leads** suggests that there is no market, or you need to find a better way to reach it. If external information strongly suggests a market exists, but you're failing at this stage of the funnel, you need to try new ways to reach your market, and it is probably too early to invalidate your product approach.
- A sufficient number of **market-qualified leads** and a lack of **problem-qualified leads** suggests that while you've identified a market, the problem you're trying to solve isn't common or significant enough. Alternatively, this could mean that your sales approach is not targeted enough. Try to learn from the **problem-qualified leads** that you have — are there things they have in common that might make it easier for you to target others with this problem at the top of the funnel? Otherwise, you may need to look for a new problem to solve for this market.
- A good number of **market-qualified** and **problem-qualified leads**, coupled with a lack of **solution-qualified leads**, suggests that your product is not solving the problem you've identified. Sometimes, this means you need to try a new approach. Alternatively, it could mean that you need to be more targeted in your sales approach to target leads that you have a better chance of being satisfied with your product. Being more targeted in the short term can allow you build a solid business to later expand your focus towards other niches with the same problem, but that requires a slightly different solution.
- The gap between **solution-qualified** and **converted** leads is probably your product roadmap — the things you need to change and improve to better cater to your target customer. This is also where the hands-on approach of account executives has a significant impact, so failure at this stage sometimes means the sales approach needs to improve.

What is notable about the advice above is that there are often sales and marketing solutions to these adoption roadblocks. By focusing too much on the product side of product-market fit, sales problems start to look like product problems.

## The case against sales innovation

The flip side of this argument is the idea that great companies address severe problems with groundbreaking products, to the point that the acquisition model doesn't require any innovation because the need for the product is so great. Based on this, the most ambitious founders should focus purely on product innovation and abandon any ideas that require experimentation to find an adequate sales model. This mindset is fair if your goal is to create the next Tesla, AWS, or Facebook. But, it also leaves a lot of complicated, niche, and highly-valuable problems unsolved. Every problem too small for the most ambitious entrepreneurs is an opportunity for others to create some serious value. For these opportunities, sales model innovation is one of the key reasons why it often takes multiple attempts from different parties to solve old complicated problems.

Tags: advice, startups, sales

# Operationalise product design to empower engineers to move faster

Investing in product design (_i.e.,_ user experience and user interface design) can lead to fantastic outcomes for product development teams of all sizes because it reduces the number of iterations required to produce a great product or feature. However, most product companies approach product design in manner that excessively slows down the development of new solutions and blows out budgets. This has led to product designers being ostracised from many initiatives and decision-making processes/rituals. By embracing a DesignOps approach to product design, companies can instead move faster and get more done with less resources.

Historically, user experience/interface design has been thought of as a distinct stage of the software development lifecycle. After an idea had been prioritised and outlined, and before development started, designers would conduct user research and visually design how a feature should work. This meant that the design phase could delay the engineering phase by weeks or months, frustrating management, product managers, engineers, and stakeholders. With the ascent of agile software development, many steps have been eliminated from the typical software development lifecycle in the spirit of spending as much time as possible building rather than planning, testing, and releasing. This industry-wide transformation has left product design in an awkward position. In most companies, it has either remained a distinct and anti-agile phase of the delivery pipeline, or it has been nearly eliminated from the process all together. Both of these approaches are bad for product development outcomes.

Product, engineering and design leaders have been slower to operationalise the product design process than they have other stages of the software development lifecycle. I believe this has happened because product and engineering leaders do not understand product design well, and many designers believe that design should be a distinct phase of the delivery pipeline. So, rather than adapting to agile development philosophies, many designers have instead fought to maintain the status quo of user experience/interface design. In contrast, the most effective teams I've worked with have all ratified the agile movement and moved towards DesignOps, a similar transformation to the DevOps movement.

DesignOps is a powerful approach because it allows teams to operationalise product design, which removes it as a roadblock in the development process. This benefits designers massively because it kills the perception that design is expensive and slows teams down, therefore giving designers more of a seat at the table than they ever have in the past.  A product team that has fully embraced DesignOps is one that has established standardisation in every area of product design (as per [DRY software engineering principles](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)). They spend most of their time building tools, reusable design patterns, and guidelines that empower designers, product managers, and engineers to make great design decisions. This means that most design work is done outside of the software development lifecycle and is focused on building dependencies that help to speed up the process, rather than interjections that delay value delivery.

## Getting started with DesignOps

Below are some principles that teams can adopt to move towards DesignOps.

First, **lose the assumption that _engineers cannot make design decisions_.** Product designers should want to get out of the way of the software development process. For this to happen, engineers need to make their own decisions around  how interfaces should look and work. Enabling this is the goal of product designers in a DesignOps environment. They achieve this by building reusable patterns, best practice guidelines, and by coaching engineers and product management. This is easy for some organisations and very difficult for others.

Second, **build a library of reusable design patterns.** This is the most critical first-step towards design standardisation, and one that many teams have already adopted. The goal here is to have a single place where all design components can be found and used by developers, coupled with good documentation on how each component should be used. Your user interface should directly utilise these components from an upstream dependency, so that you can update once and immediately rollout everywhere (_e.g.,_ changing the colour of your call-to-action buttons across the entire application should be quick and easy). Modern front-end development frameworks (_e.g.,_ React) make this easy through their use of components.

Third, **set the vision through concept design.** Instead of designing each individual feature shortly before it is to be developed, I encourage designers to create and maintain a concept for how the overall application should look and function in the future. This is a North Star that development teams should iterate towards as they develop the app. Sometimes, engineers will intentionally build things differently to how they look and work in these concepts and that is OK. Concepts will evolve as each team, and the designers themselves, learn more through research and experimentation. This decouples design strategy from any individual initiatives and instead enables all initiatives to push the application design in the same direction. 

Next, **focus on learning through research.** Traditionally, designers have conducted user testing for new features before they are built and/or before they are released, which interrupts the product development process. Instead, designers should focus on testing existing user interfaces to build a body of knowledge that challenges design assumptions that have already been made, with the purpose of improving the design system. This is possible because existing reusable patterns and guidelines are good enough to enable engineers to release features to customers without much direct input from designers. This research will result in initiatives to improve existing design patterns as well as initiatives for teams to redesign specific interfaces and workflows.

Finally, **standardise everything.** Beyond user interface design components, there is a lot more that product designers should work to standardise. For example, to ensure high-quality research, standard practices and procedures should be established (_e.g.,_ how to recruit customers, how to record feedback, how to outline problems to be addressed in the future, how to commit changes to long-term concepts). 

The paradox of DesignOps, like DevOps, is that practitioners seek an unattainable goal: a way of working where engineers can be constantly delivering value with no speed bumps along the way. Inevitably, all teams must occasionally break the principles of DesignOps. Designers need to get involved in individual initiatives from time to time. By working towards this goal, however unattainable it may feel, designers can become ROI-multipliers whose work speeds up the development process, rather than slows it down. They can finally take their seat at the table by embracing agile development rather than fighting against it.

Tags: advice, startups, operations

# How to build for your market, not the next deal

Most startups are idea-rich and resource-poor. Founders and product managers are constantly bombarded with feature requests, so a lack of ideas is rarely the biggest problem. At the same time, startups typically try to achieve something ambitious with limited resources. Startup success is thus heavily dependent on what you say _yes_ and _no_ to and how you prioritise these initiatives against each other. I encourage teams to focus on complex problems faced by many rather than those faced by few. This is the best way to differentiate your product and find product-market fit.

It can be challenging to determine how in-demand a feature will be. Early-stage startups typically rely heavily on the domain experience of their founders (one of many reasons why founder-market fit is crucial), feedback from early customers, and much guesswork. A more mature startup has a customer base that is more representative of its market, so it can instead rely on quantitative data from its customers to understand the market. Building for your market rather than specific customers is critical to getting real ROI from constrained resources. Startups that build too many customer-specific solutions may never achieve product-market fit. They end up with many complex and custom configurations (no two customers look the same), competing priorities that are difficult to manage (_e.g.,_ customers of one profile urgently require one thing, customers of another urgently require something completely different), very long customer onboarding cycles (because each new customer requires special attention and customisation), and a terminal lack of focus. In contrast, startups that focus on market solutions (and avoid customising their product based on the needs of individual customers) grow faster (because each new feature improves their product-market fit and they can onboard new customers faster), stay focused and have an easier time prioritising future opportunities. 

In the early days of building a product, prioritising solutions for the market over solutions for individual customers is much easier said than done. Because your product is immature and may not do enough to satisfy the average customer in your market, it usually feels like every new customer has some custom request you need to acquiesce to in order to close the deal. While startups with comfortable runway may have the luxury of saying "maybe later" to all of these requests and instead growing slowly towards product-market fit through a strong commitment to only building solutions for the market, many startups get their first few wins and keep the lights on by tolerating custom requests. While either approach can work fine, SaaS solutions must commit to their market as early as possible.

Complexity is another essential dimension of opportunity prioritisation. The best way to differentiate your product is to solve complicated and intimidating problems for your market, but many startups get caught up on commodity features. While commodity features solve challenges for your base, they are so simple that others have already solved them. It may make sense to build these solutions eventually. Still, startups that focus too much on commodity features tend to find their only opportunity to differentiate is through lower pricing, and they tend to grow pretty slowly. They also struggle to resource the more fundamental problems their market faces because their resources are spread too thinly across many small solutions. By prioritising the most significant and most complicated problems faced by your market, you can become the most valuable product in your customers' stack. This focus makes your product sticky, highly valuable, and easy to sell.

![Focus on complex problems](https://static.fastertimes.cloud/post-attachments/complex-problems.svg)

Combining these two dimensions of prioritisation can make it easier to determine how to spend your time:

- Complex problems pervasive in your target market will differentiate your product. It would be best if you spent as much of your resources as possible solving these problems.
- While it may make sense to tackle simple problems that your target customers commonly experience, try to outsource this to the ecosystem through partnerships with and endorsements of other solutions.
- Addressing complex problems for only a tiny market segment is usually a waste of valuable resources. Often, you can indirectly solve these problems by building outstanding APIs that enable customers to solve them themselves. However, this TAM-expanding initiative should come after you have achieved product-market fit. Diverse B2B markets sometimes have many segments with specialised needs. In these cases, building outstanding APIs may not be enough. You might need to foster an ecosystem of third-party professional services developers that can create solutions for your customers with your product at the core.
- Simple, unique challenges don't need to be addressed.

You need organisational discipline to focus on the right things and not be distracted by the wrong opportunities. You also must be capable of determining how common and complex the problems you are prioritising are. For this, domain expertise is critical in the early days, and as your startup matures, you need to build operations to measure and challenge these assumptions.

Tags: advice, startups, strategy

# Build simple, self-improving systems to reduce waste and improve momentum

Despite all startups being resource-poor relative to what they are trying to achieve, many founders invest in solutions (_e.g.,_ specific product features, technology improvements, and internal systems/processes) that require effort beyond what is desirable from an ROI perspective. This happens for many reasons: founders might be taking advice or inspiration from larger companies who need more than they do, they may fail to focus on desired outcomes, or they could underestimate how much work is required for the solutions they're championing. Most scale-ups and larger companies also suffer from bloated solutions. My advice for getting things done with minimal waste is to focus on outcomes and problems without getting too attached to the obvious solutions, try to home in onto a minimum effective dose solution, integrate processes into ongoing operational rituals, and to frequently reflect on how these things are performing to ensure continuous improvement.

Jumping to solutions is the first mistake people tend to make when solving problems. Solutions often arise first, with the problems they solve being implicit and undefined. By committing to an approach before exploring the problem, you are at a high risk of implementing one that requires more effort than is necessary to solve the problem — it might not even solve the implicit problem you're attempting to address. Defining the problem and finding consensus from stakeholders is the oft-skipped initial step toward overcoming any challenge. Whether your goal is to address a challenge faced by your customers (most likely to require some new product functionality) or an internal issue/inefficiency (most likely to require a new process), by outlining the problem in a way that does not mention any specific solutions, you give yourself a way to later determine what proposed solutions will best resolve the outlined challenge.

For example, most companies eventually need a process for onboarding new staff. There is rarely a defined process for onboarding the first few employees at an early-stage company, leading to pain as the team grows. Solutions to this problem immediately come to mind for most people (_e.g.,_ "we need an induction program for new employees that involves some technical training, social introductions and shadowing"). These solutions seem so apparent that most teams will go ahead and invest in building this out without giving too much thought to the specific issues being solved. Teams that inspect the problem first may notice that new employees only struggle with particular elements of starting in their roles, and parts of the solution that seem obvious are unnecessary. For example, new starters might not have much trouble getting their heads around their roles' technical side; therefore, the onboarding training element can wait until later. Additionally, there could be challenges for new starters that are relatively unique to the company and have been missed from the obvious solution. 

Notably, while there are many problems that most organisations face in common, the details vary significantly, and solutions should too. Teams that take the time to outline their challenges and desired outcomes before they get attached to specific solutions will find more targeted, less wasteful answers (_i.e.,_ don't include as much work that will prove unnecessary). The best solutions embrace the minimum effective dose principle: what is the slightest investment of effort we can make to solve this problem effectively? In product development, the minimum viable product framework is a well-established application of this principle, but it also applies to internal processes and tools. By focusing on outcomes and the problem to be solved, teams can reduce the scope of their solutions to a fraction of their initial idea, allowing them to depend less on risky assumptions and more quickly move on to the next problem. MVP-skeptics often criticise how the MVP approach can lead to a wide range of good enough solutions or features and nothing that goes deep enough to differentiate the product or business from the competition. This happens when teams do an excellent job of reducing scope but fail to iterate on what they have built.

Iterative improvement is key to starting small to move quickly and create something great. The best products, processes, and solutions are self-improving. For products, this means they have teams that own them long-term, without too much on their plate at once, that not only start small but consistently invest in delivering frequent iterative improvements. For processes and business operations, this means ensuring somebody is responsible and accountable for reflecting on how well they work and improving them over time. Ideally, the performance of operational tactics is measured. Business operations that are ownerless and unmeasured inevitably fall by the wayside. For example, someone (_e.g.,_ HR managers, team leaders, or recruiters) should own the aforementioned onboarding process and performance measures (_e.g.,_ employee NPS for new staff, time until effective) should be associated with them. Opportunities to improve any process should be identified and prioritised as a regular review of how that process is performing. If this feels too demanding, this could indicate that a process is not required to solve the problem (_i.e.,_ if the solution feels too big, the problem may be too small). Capturing feedback from stakeholders is another critical component of constant improvement. Consider this when building products (feedback gathering should be integrated into user interfaces) and business processes (impacted stakeholders should be surveyed on the effectiveness of the process), and try to incorporate feedback into reflection rituals like retrospectives and reviews.

Lastly, when building new features or implementing new processes, it is valuable to create internal documentation as you go. Internal documentation is an ideal location for capturing feedback and enabling others to contribute to the process. An open and collaborative business operations culture is the best way to encourage the evolution of processes over time.

Tags: advice, startups, highlights, operations

# Focus on momentum to build the factory, not just the product

Startup success is all about momentum. This is because startups do not have a great starting position to fall back on — they typically start with no customers, a small team, and no viable product. This means that you're catching up for as long as you're a startup. You're catching up to the incumbents you're trying to disrupt, to the competition which got a head start, to unrelated businesses with whom you're competing for investment capital. 

In a startup, momentum manifests through your growth rate, the rate of improvement for your product and operations, and the rate of learning (because startups operate in an environment of uncertainty, learning is critical). When you're moving at maximum velocity, it doesn't matter that others have more customers, a better product, and a lot of intellectual property because you are moving faster than they can, so you will eventually catch up. And, if you are sufficiently differentiated, they will struggle to respond. This is how seemingly unthreatening challenger brands disrupt incumbents in the long run.

The best founders embrace their underdog status. They win by moving quickly and doing things radically different to their competitors. Absolutes are less important for early-stage companies because they are moving swiftly. When searching for product-market fit, they push almost recklessly, committed to learning as much as possible about their market and what could solve its most significant problems. After achieving product-market fit, the best leaders focus more on building an engine for growth rather than implementation details. What matters most is that the company can move quickly, whether it comes to decision-making, revenue growth, or product development. When these areas are healthy, their strategy can be more flexible, and they can adapt to their new learnings and the conditions of the market and ecosystem.

As a leader scaling a product into a discovered market, your time is usually best spent creating the environment for fast-paced growth rather than directly growing the company yourself. For example, in product development, it is critical to build the factory, not just the product. Many companies have built electric car prototypes, but very few have scaled these into production. This is because the organisational competencies required to create a proof-of-concept are different to the competencies needed to scale a product. This applies to software, too. It's easy to build a simple software product that solves a specific problem for a small audience. Building reliable software that addresses the needs of a big enough market with outstanding reliability can be very different. It usually requires the efforts of many, so things like centralised/top-down decision-making and a tendency toward big bets can stop working. Leaders who work too hard to retain a tight grip on the decision-making of product development outputs are more likely to fail than those who instead focus on building a strong team with scalable operations that can execute without too much direct influence.

The principle of momentum over starting position is applicable to almost any operational challenge in a startup or scale up. A straightforward and achievable first version of something new, coupled with sound operations and discipline to improve it as needed, is usually better than investing significant time into your current understanding of an optimal solution for that problem. A company in need of a process for to solve a problem (_e.g.,_ onboarding new staff) is better off implementing a very simple process that can be established in a week, coupled with great mechanisms for feedback to be collected and improvements to be made to the process, than if they were to invest in designing their ideal onboarding process upfront, followed by weeks or months of work to implement this untested process. By focusing on the [minimum effective dose solution](https://www.oxfordreference.com/view/10.1093/oi/authority.20110803100159919), you can eliminate most of the problem quickly. By employing solid operations for learning and iterative improvement, you can gradually build towards a more robust and optimised process than you could've designed upfront.

Tags: advice, startups, strategy

# Professional services for SaaS companies

Professional services are a component of many B2B SaaS businesses, especially in the enterprise space, where [most vendors make around 20% of their revenue from services](https://www.saastr.com/how-much-should-a-saas-company-invest-in-professional-services/). Usually, these services take the form of onboarding services provided to help a customer to get set up with your product after they've first become a paying customer. 

For many enterprise SaaS products, a layer of professional services is essential because enterprise customers tend to have diverse needs from each other. Professional services enable deeper customisation on a per-customer basis while keeping the core product focused on the target market rather than the needs of specific customers. Another benefit of providing in-house professional services is that they can provide a significant revenue stream during the early days of finding product-market fit. Many bootstrapped companies use this revenue to keep the lights on as they build recurring revenue momentum.

Unfortunately, there are also many downsides to relying on professional services as a SaaS company. For example, by building a product that depends on configuration by a professional, you can seriously hinder the growth momentum of your company. This is because professional services teams can be tough to scale. So while the model works great when you only have a few customers coming in each month, companies often hit a breaking point where they cannot scale their professional services team as quickly as their SaaS product wants to grow. This results in sales teams having to slow down or professional services teams becoming overcommitted. 

Another risk is the risk of distraction. Professional services are not core to the mission of any SaaS company, so when they become a bottleneck and, therefore, an area that constantly requires attention from management, they can seriously distract the business from the things that will drive recurring revenue growth. Similarly, by relying too heavily on professional services, SaaS companies often turn into professional services companies who rely much more heavily on professional services revenue than recurring revenue (when this happens, valuations given during initial fundraising can become increasingly unrealistic). Dependence on professional services revenue can kill SaaS companies because it creates a catch-22 where the company needs to invest in product development to make their product more self-service (and, therefore, easier to grow as it is less dependent on professional services). Still, as professional services work is urgent and keeps the lights on, it always gets prioritised over product development work.

As a SaaS business, challenge yourself to see if you can deliver a great product without professional services. Self-service products tend to have the best economics and the most unhindered growth, especially products compatible with a product-led growth model. Companies that start with a dependence on professional services often struggle to imagine a self-service future for their product, but this is achievable more often than not.

If this is not possible, explore outsourcing the professional services component of your product to third-party professional services companies with whom you can partner. For some products, this is easier than others. For example, products built within an existing ecosystem (_e.g.,_ marketing products or add-ons platforms like Salesforce and Shopify) might have an existing network of professional services agencies that they can tap into and refer business to instead. 

If all else fails, embrace internal professional services, especially if you service the enterprise market. If you don't service the enterprise market and cannot provide your product without a layer of professional services, you should consider going upmarket and targeting enterprise in the future. If you find yourself in this situation, there are a few things I recommend considering carefully.

First, make sure you have outstanding leadership in your professional services team to avoid unnecessary bottlenecks in the customer journey. Try to hire ahead of your needs so that your sales team does not need to slow down while you recruit new professional services staff. Professional services teams tend to have poorer retention rates than engineering teams, so try to keep these teams happy and well-resourced to limit the negative impacts of potential staff churn.

Second, keep your pool of resources for professional services separate from your product, engineering, and support resources, and commit to spending at least 30% of your Annual Recurring Revenue on product development. This will stop you from falling into the trap of neglecting the development of your product (and your journey towards becoming more self-service) because of short-term urgencies in the professional services team. If this feels unrealistic for your company, I'd recommend increasing your prices for either/both your professional services and your SaaS product.

Lastly, report on professional services costs and revenue separately to your SaaS reporting. Never include professional services revenue or expenses in your calculations for ARR, ARPU, CAC Payback, SaaS COGS, LTV:CAC, or any other SaaS metrics. To succeed as a SaaS business, you need an honest view of the health of your SaaS business. As nice as professional services revenue can be, it does not factor into the health of your core SaaS business.

Tags: advice, startups, strategy

# Principles for structuring a product development team

> At my company, we are going through a reorganisation of our product and engineering teams. Do you have any universally applicable advice for leaders trying to structure their product development teams?

While every company should approach this somewhat different, there are a handful of principles that apply to most product companies that I think you should consider.

First, I recommend embracing a model where product and engineering are united under a single organisational department (e.g., _product development_, _R&D_, or _technology_). This is a simple first step towards bringing these teams together and eliminating blame, finger-pointing, and poor communication.

From here, I recommend cross-functional teams. Despite being one of the most misused buzzwords in business, organisations built from cross-functional teams really do scale much more effectively than organisations with too many functional silos. Cross-functional teams are teams that are united by a common goal, rather than a common profession or practice. A cross-functional team might be a group of designers, engineers, product managers and product marketers that are all rallied around a single problem they are trying to solve, whereas a functional team is a group of people brought together because they share a specialisation (_e.g.,_ all product designers might work in a single team).

![Cross-functional teams consist of people with diverse specialisations. Functional teams consist of people with very similar specialisations.](https://static.fastertimes.cloud/post-attachments/cross-functional-versus-functional-min.svg)

These days, small cross-functional teams are the norm for product development departments, while sales, marketing, and support departments are typically grouped by function. Cross-functionality is a spectrum and while it's generally better to be more cross-functional than less, the sweet spot is different for all companies. The practicality of a cross-functional organisational structure also varies with the maturity and size of the company. For example, in the early days, most startups are one small cross-functional team out of necessity. As startups grow, though, departments start to form around senior leaders who own a function. Large companies are often resourced well enough to once again enjoy a higher degree of cross-functionality.

Organisations built from cross-functional teams scale better because they rely less on centralised decision making. In a functional organisation, to make a decision that requires the consultation of multiple functions, a lot of communication and negotiation must be done across teams and this can be incredibly slow. It also means a lot of important decisions are made by members of leadership who may not be close enough to critical information that should impact decision making. Cross-functional teams that have a healthy level of representation from the various functions within a business can be more independent and autonomous, which results in both quicker and better decision making.

While I strongly recommend employing the cross-functional teams pattern when structuring teams, in contrast, I recommend functional lines of reporting from an organisational chart perspective. This means, where possible, designers should report to designers, product managers should report to product managers, and engineers should report to engineers. This can complicate your organisational chart because it decouples reporting lines from day-to-day teams (many staff end up in two teams, their functional team and their cross-functional team), but it is critical in order to provide great career development, coaching and mentorship for team members, and to encourage the continuous improvement of how you approach each function.

![Functional lines of reporting are not incompatible with cross-functional teams.](https://static.fastertimes.cloud/post-attachments/alignment-to-teams-working-groups-min.svg)

A common anti-pattern to avoid at all costs is the temptation to have product development team members report to the product manager leading their team. This may seem like a logical way to structure your company because it is technically cross-functional and it puts responsibility into the hands of the person perceived to be the leader of the team (the product manager), but at scale, it always leads to conflicts of interest (product managers are managers of a lot of things, but they are members of the team, not managers of the team), deprives engineers and designers of mentorship from someone experienced in their field, and distracts product managers from their core responsibilities.

The last principle that applies to most teams is to decouple technical leadership from people management within engineering reporting lines in larger organisations. This means the people leaders (often _engineering managers_) who take care of people from a satisfaction, career growth, and general HR perspective are not the people who take point on technical direction and leadership. Separating these roles explicitly is the only way to ensure excellence in both areas at scale, because anyone juggling these separately will inevitably focus more on the area they're most interested in, and there is always more work to be done in both fields. This principle also applies to any other function with many employees doing very similar work. For example, at scale, it's best to separate training and quality assurance for customer support teams from people management, otherwise one will likely fall by the wayside.

Tags: advice, startups, operations, people

# Customer success for startups — how to get started

Customer success is a critical function within B2B software companies. It is typically staffed by customer success managers who are tasked with managing the experience of existing customers throughout their journey with the product, with the assistance of automation. Every B2B software startup eventually finds itself in need of a customer success function, but most struggle to spin one up without a few hurdles and misfires. This is because the focus of customer success is very broad, with diverse goals and roles required to succeed.

The best way to think about the customer success function is through the lens of the diverse goals this department is usually aligned to:

- **Retention.** A common purpose for customer success teams is to act both proactively and reactively to retain as many customers as possible. Proactive customer retention usually looks like checking in on customers who might be struggling to find opportunities to help, and this is usually data-driven (_e.g.,_ we know that customers who don't do 𝑥 very often are likely to churn, so we prioritise checking in with them). Reactive customer retention involves responding to cancellation requests or getting involved in customer issues that are severe enough to lead to churn (including the following up of unpaid invoices). Success measures for customer retention include your retention/churn rates for both customers (_i.e.,_ logo churn) and revenue (_i.e.,_ MRR/ARR churn) as well as CSAT and NPS.
- **Revenue expansion.** ARR/MRR expansion is any additional revenue you make from existing customers who are increasing their usage of your product. This role feels a lot more like a sales role, and generally involves reaching out to customers proactively to encourage them to adopt more products or more features of your product. While this also helps with retention in the long-term (because customers who use more of your product are less likely to leave), the primary success measures are positive revenue expansion and limited revenue contraction, as well as other measures to represent utilisation (_e.g.,_ number of features actively used).
- **Onboarding/Activation.** For most products, customers are most likely to churn during the onboarding phase, which occupies the period of the user journey after sales but before a customer has fully adopted your software (this is because the customer is _paying_ for the product, but not yet _getting much value_ out of it, so during this phase of unrealised return-on-investment, they are most likely to give up on the product). This is why many companies dedicate customer success resources towards helping new customers to _activate_ the software and get to a place where they are experiencing (and aware of) the value of the product. Mostly self-service products might only require a quick phone call (or might rely entirely on automated email or in-app communications), while products that require customisation and implementation often rely on internal or external professional services to get things working for the customer. Success measures here are diverse and often involves tracking how long it takes for a customer to get to value.
- **Account management.** Some customers require a single point of contact. This usually takes the form of an account manager (or dedicated customer success manager) who manages a portfolio of customers. This is common in enterprise SaaS, where individual customers might have a lot of support tickets, feature requests, and professional services projects in play at any given time, causing a need for cross-team coordination for each customer. Success measures for account management is similar to retention, mostly focused on retention/churn rates and NPS/CSAT.

If you've made it through the wall of text above, you're probably thinking "that is a lot for one team to take on," and you're right. Customer success is a diverse function and the primary reason most startups initially fail to roll it out is that they don't have a clear idea of what they actually need from their first customer success hires. When establishing your customer success team, it's important to consider what problems you are trying to solve:

- If customer churn or customer satisfaction is the problem, you should focus on retention.
- If you're trying to better monetise your existing customers, expansion is where you should focus.
- If you are struggling to get customers active and engaged after the sales process, then onboarding/activation is what matters most.
- If your high-value customers are unhappy, then account management might be part of the solution.

Most startups will kick off their first foray into customer success through just one or two hires. Unfortunately, most of the time, just two people can't handle all of the responsibilities for customer success. This is why it's important to be very specific about what problems you are initially trying to solve and to keep your first hires focused in these areas until the team grows and you can better spread your resources across the various responsibilities of customer success. Similarly, it is also important to know what type of employee(s) you need when establishing your team:

- Customer Success Managers who are focused on revenue expansion often need to be well-suited to a sales role.
- Activation Managers who are focused on onboarding new customers often need to be more technical.
- In some companies, Account Managers need to be very technical.

Like all teams, customer success is best resourced as a patchwork of people with diverse specialties and experience. The type of candidate I would hire for the typical revenue expansion role is different to the type of candidate I'd typically hire for technical account management. By focusing on just the most important customer success responsibilities when you are making your first hires, you have a much greater chance of success. As you expand the responsibilities of your success team, you can hire people with other specialities, and eventually cover all bases.

Tags: advice, startups, operations

# Focused solutions are best; feature requests tend to snowball

The ideal state for product-market fit is to have an extremely narrow and focused product that satisfies a very broad market. Products like this can satisfy a huge market with less investment and less distraction. The ability to satisfy a large market with less investment directly translates to potential profitability because market size influences potential revenue. The ability to satisfy a large market while staying narrowly concentrated in your product development efforts directly translates to your ability to continue to satisfy your market in the long term because by focusing on your target customer, you can be constantly improving the product for them without unnecessary distractions. The long-term viability of a product is dictated by these factors of how big the market is, and how focused the product can be. These factors are decided by the problem you are solving, and who you are solving it for. The art of keeping a sufficiently narrow solution requires you to pick the right problem for the right market, and practice discipline when building your product in order to avoid any unnecessary distractions.

Most companies stumble across a market with a problem and spend most of their early-stage investment on finding the solution. So, while you can be strategic about choosing the right market and problem (mostly by pivoting to different problems that your target market is facing, or solving the same problem for a different target market), most companies leave this up to luck. What should never be left to luck is the discovery of a solution for your market. This is where great product management principles and operations can make or break a startup, and much of the time this means prioritising the right solutions and finding the best way to tackle them. Stay narrow. Be excellent.

![Narrow solutions for a large market are both easy to win and present a great opportunity.](https://static.fastertimes.cloud/post-attachments/solution-complexity.svg)

_Rabbit hole features_ are one of the most common pitfalls for product companies. These come in all sorts of shapes and sizes, though most often they emerge as feature requests that will expand the scope of your ideal customer profile. For example, when building a product for physical retailers, you might get a lot of feedback from your sales team that if you only had one or two extra features, the entire solution would be sellable not only to retailers but to hospitality businesses as well. The idea of being able to sell your product into an entirely new market with very little effort can be a really attractive opportunity, so these features often get built without much hesitation (hospitality is a huge industry!). 

The problem is, these requests are usually _rabbit hole features_. A _rabbit hole feature_ is a feature that always leads to additional essential feature requests. The fact that you don't have the most important features for a specific market is stopping you from getting enough feedback from potential customers in that market, so as soon as you start to onboard customers from a new market, feature requests start to pour in. The outcome of building _rabbit hole features_ is usually a very modest expansion to your addressable market, at the cost of a loss of focus and worse economies of scale in your support team, because customers in this new market need a lot more attention than what you've planned on giving them. 

![To keep customers happy, you'll need to do more than just the essentials.](https://static.fastertimes.cloud/post-attachments/pyramid-customer-needs.svg)

The worst part about this situation is that these things are usually fleeting opportunities, so businesses quickly forget about all the times they've failed to quickly add a new industry vertical or use case to their repertoire. This means many companies make this mistake many times.

The lesson here is to only ever enter a new market segment if you plan on resourcing it for long term continuous improvement. Stay focused on the broader market you are targeting, not specific deals that come through the door on any given day. The best indication that you've discovered product-market fit, is that you are turning away deals that you don't need because you know they don't fit your ideal customer profile.

Tags: advice, startups, strategy

# To build or to buy (or partner): a guide for startups

Startup leaders are constantly facing decisions of whether they should build something themselves, or buy an out-of-the-box third-party solution. I believe startups should be biased against building anything inessential that doesn't pose a legitimate opportunity to create a competitive advantage. In other words: only do what you're positioned to do better than anyone else.

For engineering leaders, this question is most often regarding behind-the-scenes tooling or dependencies. It could be something as simple as whether it is ok to depend on a third-party open source library for some simple functionality, or it could be something more fundamental like whether it is better to use a third-party SaaS product for something like [feature flags](http://flagsmith.com), as opposed to building something in-house. 

For product leaders, this question can also pertain to product features, though instead of _buy_, the alternative to _build_ is more likely to _partner_ (_i.e.,_ integrate/collaborate with a third-party who already solves this problem). This is because most products exist within a broader ecosystem, so many of the problems your customers need solutions for, have already been solved by others. For example, when building an ecommerce platform that is differentiated by providing a fantastic shopping cart experience, you might choose to partner with another product that specialises in marketplace integrations rather than build them all out yourself. This is beneficial to both companies, who can remain focused on their areas of differentiation, and are now stronger together.

In either case, the guiding principle needs to be opportunity cost above all else. Startups succeed by solving one big problem the best way possible for their market, and any work that is not directly related to solving that problem should be highly scrutinised. Where possible, work that distracts you from obsessively proving the core hypothesis of your business should be avoided. Building your own solution for something (e.g., _feature flags_) might seem easy enough and could also be an opportunity to save ongoing costs, but this measure of return on investment does not consider the cost of being distracted from your core mission as a product.

Whether it's a piece of common technical infrastructure (_e.g.,_ feature flags, analytics, email delivery, or payments) or a tool to help your team to acquire and service customers (_e.g.,_ a product knowledge base, support hub, or marketing website), an out-of-the-box solution is most likely the best path. Sometimes, legitimate opportunities to differentiate a product through custom internal tooling will arise (_e.g.,_ some product categories are difficult to tackle because they are too expensive to provide customer support for, forcing businesses to differentiate their products through internal tooling and automation that makes support more efficient and might not be directly related to the product itself), but it's best to be sure about these before distracting your team.

Solving product feature requests through partnerships with other SaaS providers can be a great way to reduce roadblocks for your sales team without committing product development resources towards problems that are only relevant to a subset of your market, allowing you to remain focused on building solutions that will be valued by the majority of your customers. Smart product teams will often integrate with a third party and reassess the desirability of an in-house solution down the track. Often, it is discovered that the third-party solution is more than adequate to keep customers happy, and teams can continue to focus elsewhere. Alternatively, teams might discover that there truly is a great opportunity here that should be explored more deeply.

Another way for product teams to respond to distracting requests that are pulling them away from their core focus is to prioritise the extensibility of their product, and rely on professional services partnerships to provide customisations where necessary. This approach is especially useful when the solution to a problem is not clear, and different approaches for different customers are likely to be required, though it usually only works for products that are targeting larger enterprises or developers. Typically, this means the product development team will build APIs to enable third parties to build the requested functionality and work with a third-party professional services company to build the feature for their customer. This approach keeps their core product narrow and focused, fosters a professional services ecosystem around their product, and removes roadblocks for future prospects who want to solve this problem in their own way.

The build or buy question is often difficult to answer, but it is made easier when product teams are focused on building towards greater differentiation, with an adequate level of scrutiny built into their prioritisation processes. By considering what you are delaying in order to build something you could otherwise outsource, you will form a better idea of the real cost of this work.

Tags: advice, startups, strategy

# On finding and measuring product-market fit

Products with product-market fit are products that have found an adequately sized market that they can be sold into. It's more of a spectrum than a binary state — some products are more suitable for their market than others.

The first step of finding product-market fit is to identify the market. Is there a (big enough) cohort of businesses or consumers with the same problem to be solved? To scale a product into a market, there needs to be enough of an audience to target. Some products solve big problems for so few people that they are simply not viable businesses, despite how valuable they may be to early adopters. This is why simply having sold your product to a handful of customers does not necessarily mean you've found market fit. The second step of finding product-market fit is to find an adequate solution to the identified market problem. What is the one-size-fits-all way to solve the problem you've identified for a large percentage of the people in your target market? For some founders, this comes easily. For others, it can take a very long time. 

If you have found an adequately sized group of prospects who share a similar problem, and have built an adequate solution to that problem, you've found product-market fit. You're probably finding it easier than ever to find new customers, and your product vision is stabilising.  If you're struggling to focus your product development efforts in a single direction and cannot commit to a specific ideal customer profile, you've probably not found product-market fit.

While the market (i.e., _the problem_) comes first, and the product (i.e., _the solution_) comes second, discovery rarely actually plays out this way. Rather, most startups will start with a hypothesis for _both_ the problem and the solution and through experimentation these assumptions are tested. Some startups get the market right from the start, and require some experimentation to find the right solution. Others might surprise themselves with which market ends up most in need of their solutions. Most are at least somewhat wrong about both market and product, and will pivot their way towards a more solid product-market fit hypothesis.

Consistently high sales momentum coupled with consistently low churn is your best measure of product-market fit. Given product-market fit is a spectrum, some businesses will find enough customers to convince themselves that their hypothesis for their product is correct, but won't find enough customers to achieve the type of scale they need. This can simply mean they haven't actually found product-market fit. This is a trap that a lot of businesses fall into — they have enough fit to exist as a business, but not to achieve scale. This leads to stagnation and a slow death.

Stagnation, after an initial period of growth, can also be a reflection of the fit between not only product and market, but also market and sales model. It is possible to find a market, find a great solution for that market, but fail to work out how to sell into the market. This is why experimentation should not end with product development, but also extend into go to market strategy (e.g., _partnerships, product-led growth, direct sales, SDR, are all channels that might be explored_). Product experimentation may also be required to test different types of sales strategies.

Tags: advice, startups, strategy

# On losing employees to customers and partners

While losing staff to customers and partners is a common frustration in B2B SaaS, I would advise against having any sort of non-compete/anti-poaching clause in your standard customer and partner terms[^1].

First of all, this is bad for your employees. As an employer, you should be competing in talent market by providing a great place to work, with fair compensation and benefits, not trying to lock them in with contracts they don't have any influence over and may not even be aware of. If an employee wants/needs to leave, and their best prospects are with a partner or customer, it's unfair to limit their options.

Strategically, this still doesn't make sense. Diligent businesses will not sign non-competes, especially if they are not mutual. So, chances are you will be restricting your own ability to hire staff from partners and customers, which as your customer and partner bases grows, could become very difficult to manage and ultimately harm your recruiting pipeline worse than it helps your retention rate. You will likely eventually get some of your best employees, who hit the ground running because they already know your product, from customers and partners.

Most B2B SaaS businesses benefit from a strong ecosystem of service providers and integrated solutions. Losing staff to other businesses within your products' ecosystem may hurt in the short term, but it will also likely contribute positively to the overall ecosystem for your product. For example, it can be really difficult for service providers, who are recommending your product and implementing it for customers, to train their staff as thoroughly as you can internally. Occasionally losing staff to partners who are servicing your customer base could actually be a better use of their experience in the ecosystem for your product, especially if your employees are leaving for more senior roles at companies that work with your product anyway. This is especially beneficial when your staff are leaving to start their own businesses within the ecosystem.

Another thing to consider is whether your staff would've left regardless of whether a customer or partner offered them a role or not. There's a good chance that these employees left because of unrelated reasons, and simply chose a role with a partner or customer because it seemed like a logical way to apply what they've learned during their tenure with your business. From this perspective, if you were to make it difficult for them to do this, they'd probably be more likely to work for a direct competitor, as an alternative pathway to reapply their skills. So, your former employee now works for a competitor, rather than a friendly party from within your ecosystem. Not a good outcome!

In the end, while I understand this can be disappointing and feel like a betrayal, staff churn is inevitable, and movement of talent around the ecosystem you're building for your product can be a really positive force. For all of these reasons, anti-poaching clauses are a bad idea.

[^1]: This is not legal advice and doesn't consider whether these types of agreements are even lawful or enforceable, which will vary by jurisdiction.

Tags: advice, startups, people

# How roadmaps and commitments can hamper continuous improvement

As a product company, feature requests are inevitable and it can be really difficult to resist the urge to commit to requests from customers, especially if they are features you already plan on implementing, and if a new sale depends on it (or you believe it will mitigate the churn of an existing customer). As harmless as these commitments may seem, promising future features to new and existing users almost always leads to poor outcomes and a lack of control over your product strategy, because they build up over time and eliminate opportunities to adjust course.

Many product companies are burdened by a multitude of commitments that have been made to customers and other stakeholders. Some of these might be unavoidable commitments. For example, changes to upstream dependencies (like APIs) and regulations often compel product teams to prioritise work they'd rather not do. Other commitments are often made to keep a customer from churning or to win a new deal. When early-stage companies are still finding product-market fit, these commitments can be a good way to nudge the product in the right direction. As a company matures, though, these pledges compile and result in a product strategy that product teams have very little control over. In many cases, every team is simultaneously backed up with months of work that may not be the most strategically important or valuable but instead is required to satisfy the backlog of promises that have accrued over time. The result is a product strategy that delivers on commitments made to individual customers, rather than improvements for the entire target market.

Sometimes, commitments are not made because of pressure from individual customers or other external forces. In fact, many commitments are led by product teams! Typically, this is done through the roadmapping process. Teams identify opportunities to improve their products, and they commit to these improvements by adding them to their roadmap which is visible to stakeholders like customers and partners. By doing this, teams are creating an environment where the _purpose of execution_ is to progress through a pre-defined roadmap, rather than to _solve the most pressing problems at any point in time_. This is the case no matter how much value is in the roadmap. Undeniably, there are benefits to having a firm plan for your product: by knowing what will come, and when, you can much more easily align other business activities with the future state of the product. These benefits, however, are negated by two critical factors. First, there is no way to know how long something will take, nor how feasible it may be. Therefore, having a roadmap does not actually bring any certainty to the question of when will an individual problem be solved, because they are full of inaccurate assumptions around scope and timeline. Secondly, deliverables on roadmaps are almost never outlined in enough detail for stakeholders to be on the same page about what is going to be delivered. Different customers, partners, and internal stakeholders are likely to have very divergent interpretations of what each feature on the roadmap truly means. This quickly leads to a constant state of overpromising and under-delivering. On the roadmap, customers see a feature they want, and they start to plan their business around this. After waiting longer than they expected, the feature is finally delivered, only to be implemented in a way that doesn't satisfy the needs of this specific customer, in spite of being implemented in a way that is well-suited to the broader target market for the product. Disappointment inevitably ensues.

The biggest problem with committing to a prescriptive product plan, whether via a roadmap or simply through conversations with customers and prospects, is that this always leads to a suboptimal product strategy because what makes sense today might not make sense in a months time. This is because:

- **Teams learn as they execute.** Great product teams embrace short feedback loops, meaning they release value frequently and in small batches, and they learn from these incremental outcomes. Teams that are constantly learning are constantly becoming more capable of making great decisions because they have more information and a more thorough understanding of the needs of their target market. Learnings from recent work may adjust the parameters for what makes the most sense to tackle next, so great teams lean into this advantage by taking on as little commitment debt as possible and making decisions in a just-in-time manner.
- **Circumstances inevitably change over time.** By committing upfront, you're making long-term decisions based on short-term information. Most startups operate in an environment of uncertainty. So, changes to the competitive landscape, industry regulations, and customer needs should be expected.
- **Product changes beget new opportunities.** Any change to your products' capabilities also changes your options for what comes next. A common example is circumstances where you may think that by adding a certain feature, you will open yourself up to a new (or better support an existing) vertical. You might hear a lot of "customers/prospects in this segment only ever request this one simple feature, if we had it, we'd be able to say _yes_ to a lot more deals". This is rarely the case because the lack of certain functionality not only stops certain prospects from using your product, it also blocks a tonne of feedback that you would get from those prospects. Feature requests, when executed, often lead to additional feature requests. So, if you're earnest about better supporting a segment of your market, you will most likely need to prioritise subsequent, unexpected work. This can be really difficult when your roadmap is mostly locked-in, potentially rendering the work you just completed mostly valueless until you find space to double down.

The best product teams I've worked with embrace the iterative nature of software development. Instead of committing to roadmap items, they commit to high-level, long-term goals. These goals are the focus of one or more teams for at least a year, and teams work towards these goals by tackling small chunks of work and constantly re-prioritising and re-thinking their approach. This is made dramatically easier by great DevOps practices, like automated testing, feature toggles, and highly automated releases, as this environment ensures tight feedback loops. The ability to quickly get changes out into production enables teams to quickly learn from the impact of their changes, and optimise their approach with regularity. This is a difficult approach to sell to your stakeholders, but should ultimately lead to better outcomes.

Tags: advice, startups, strategy

# Great product companies operationalise their investments in development

Today, we pay for almost all B2B software on a monthly or annual subscription. The subscription software model has revolutionised how software customers budget and pay for software costs but hasn't transformed the ways of working for software vendors as much as it should.

Businesses have always required tools to operate. You buy a device, use it, and replace it when it breaks. Farms buy ploughs, factories purchase machinery, and newspapers buy a printing press. In the early days of the software industry, companies bought software this way. If you needed Excel, you purchased the latest version and used it until you had a good reason to buy a more recent version or competitive alternative. Businesses call this process of purchasing equipment upfront [capital expenditure](https://www.investopedia.com/terms/c/capitalexpenditure.asp) because the total cost is immediate, even if you receive value from the device over time.

At first, it made sense for the software industry to mimic the existing business models employed by other tool manufacturers. But today, this business model is increasingly rare for software businesses. This is because of the rise of Software as a Service, the model where you rent software (and support services) monthly, quarterly, or annually. Low marginal costs that come with digital goods enable this model. Because software developers do not need to pay anything upfront to "manufacture" their software for each new user, they do not need to charge their customers upfront. The subscription model dramatically lowers the barrier to entry for businesses that require software as they no longer need to invest a large chunk of capital upfront. Instead, they can license any required software, paying for what they use as they use it, moving software licensing fees away from capital expenditure and towards operational expenditure (_i.e.,_ regular business-as-usual costs). In the industry, we've referred to this as the _operationalisation of software costs_.

This is all very _SaaS 101_ and probably goes without saying for most people working within the software industry. But while most of the software industry has now adopted the SaaS model and operationalised their revenue, many are yet to operationalise their investments in that they still effectively allocate capital on a project-by-project basis.

Let's dig deeper into this idea. So, we've established that as a software vendor, our customers can invest in tools either through _capital expenditure_ (upfront purchasing of tools with a limited lifetime) or _operational expenditure_ (regular business-as-usual costs). The same model applies to you as a software vendor: do you build your product through _capital expenditure_ (_e.g.,_ we will invest $450,000 into this project) or _operational expenditure_ (_e.g.,_ we invest in this product on an ongoing basis, this cost line never goes away).

In the traditional model, software companies aligned R&D investments with their sales model. We sold software products as one-off sales to the customer and built products in the same way. We calculated ROI by examining how much we spent on _ACME Software App Version 2_, and how many customers bought it. Many SaaS companies still use this outdated model for product development. They imagine new revenue lines (_e.g.,_ a new product or feature) as discrete, short-term projects with their own measures of ROI. This model is flawed because it misaligns the software vendor's incentives away from their customers' best interests.

Before SaaS, products were completed before they were sold (this sounds like pointing out the obvious, but it really is very different to how software works today). Just like any tool in the physical world, when you bought software, you bought it in its current state, and it generally stayed pretty much the same from then onwards. In the world of SaaS, customers repurchase your product every single pay cycle. The same low costs of adoption that made it easy for you to sell your product to your customer without upfront capital expenditure also make it very easy for your customer to adopt a competitive product if it becomes more suitable. Therefore, it is critical for SaaS products to improve throughout the lifecycle of a customer (though the bar for how much a product may need to improve over time varies based on the maturity of the product and the market niche you address). In SaaS, you technically resell your product to every customer every month, quarter, or year. While automated billing turns this resale into a passive process on behalf of the customer, you should still think about renewals this way: you need to remain the most suitable product for the customers in your market niche on an ongoing basis.

The best way to achieve this ongoing success is to operationalise your investment in product development, aligning your costs with your revenues. Customers repurchase your products every month, so your products must improve at that same pace. Instead of budgeting on a project-by-project basis, allocate ongoing resources towards products in your portfolio.

Practically, this looks like:

- **Align teams to products instead of projects.** Product teams are long-lived teams that own a product rather than teams that bounce between products and projects.
- **Any product with customers also needs developers.** If your product has a customer, it needs development resources to maintain and improve it. If you can't justify this for a particular product, you should probably kill this product.
- **Products are not projects.** Don't build new products with a project mentality. To build a new product, you need to spin up a team dedicated in the long term to this new product. This may not be necessary for explorations and proofs-of-concept, but you need a team when you're ready to get some customers.
- **Measure the success of your products over projects.** It's most valuable to establish long-term, product-wide success measures that all of your initiatives will work towards improving. Individual initiatives might have their own success or failure indicators, but these should align with the success measures for your product. If these become difficult to align with your product, you may be working on the wrong things. Alternatively, you may be stumbling into a new product for which you need a new team.

This transformation is much more complicated than the business model transition that most software companies have now completed. Operationalising software revenue has proven much more accessible than operationalising capital investment. However, it's essential for long-term success as a SaaS business.

Tags: advice, startups, strategy

# Taking on and paying down technical debt

A common topic in product companies is the prioritisation of so-called _customer-facing initiatives_ versus so-called _technical initiatives_ (e.g., _automated testing_, _reusable technical patterns_, _SDKs_, _automation_, _API-first services_). The debate usually goes like this:

1. We should focus on delivering customer value over anything. With our limited resources, any investment in non-critical technical work will only delay the features customers need.
2. We need to invest in technical excellence now. If we don't, we'll have reliability issues and be inundated with technical debt.

The common-sense answer for all companies is to strike a balance between these two approaches. A company should not spend 100% of its resources on gold-plated technical foundations on which no customer value is ever built. At the same time, neglecting technical foundations self-destructive in the long term.

![As products become more complex, maintenance burden rises. Paying down technical debt helps to manage this effect.](https://static.fastertimes.cloud/post-attachments/maintenance-burden-grows.svg)

One way to look at this is by the stage of the company:

1. Early-stage product companies are operating in a context of low confidence in their solutions because they are still looking for product-market fit. They probably don't have a firm understanding of what they should build because they are still exploring what problems the market wants them to solve. In this context, it often makes sense to prioritise short-term product development velocity over long-term momentum because there is not yet any certainty on what features will end up useful or even whether the business will exist in the long term. Thus, a less technically excellent approach may make sense during this phase.
2. Companies that have found product-market fit, and therefore have a pretty strong thesis for how they will scale, should be focused on scalability and optimisation. Strong technical foundations are critical to scalability and should therefore be a major focus.

The transition between the two stages above can be very difficult for product companies. In some circumstances, companies will find product-market fit before a significant amount of technical debt has built up, so starting to focus on technical foundations feels like nothing but a significant slowing of product development velocity. In most circumstances, technical debt has likely become a problem by the time product-market fit has been achieved, and the transition is even more difficult because the prescribed solution to velocity that has been slowing down (due to mounting technical debt) is a further (temporary) slowdown to pay back this debt and lay better technical foundations. This dilemma traps many companies into a very unhealthy cycle, where the bar for _technical debt to be addressed_ becomes very high (i.e., _essentially just critical bugs and security issues_), so technical work is a burden to begrudgingly be addressed, rather than a valuable investment in critical foundations. This approach gradually slows development momentum to a crawl which can kill product companies if the need to build quickly should ever arise (e.g., _disruption from competitors_).

Resistance to technical investment is understandable — the solution to delivery inertia caused by technical debt feels like a further reduction in speed of delivery _because it is_. The two major changes usually required are:

- A pause in feature development to focus on paying back debt and building better foundations for the future (e.g., _writing tests for legacy code_), thus delaying features on the roadmap for some time.
- The padding of future work with additional technical effort (e.g., _writing tests_), thus slowing down the delivery of features in comparison to what the business is accustomed to.

The value, though, is that eventually, this alleviates the already existing inertia that is compounded by a lack of investment in technical debt, with the net outcome being an increase in speed of delivery. This shouldn't just be thought of as debt, which implies that technical work is a burden to be begrudgingly addressed. Just as you can be disadvantaged by technical debt, you can also be advantaged by [technical wealth](https://legacycoderocks.libsyn.com/technical-wealth-with-declan-wheelan). Put another way, by investing more in great technical foundations, you can see benefits beyond simply paying down debt to keep things moving at an acceptable pace (e.g., _it is difficult to build in an API-first approach when you don't have good foundations and patterns for how new APIs should be built. Pausing now to build some great foundations for future API services might delay the delivery of your first API, but it will speed up the delivery of subsequent APIs and simplify maintenance in the long term_).

![When you pause to build foundations, the first feature takes longer, but you will eventually catch up.](https://static.fastertimes.cloud/post-attachments/pause-to-build-foundations.svg)

In summary, product leaders should think more about the positive outcomes of technical investment, rather than simply view technical work as a burden to be addressed to avoid negative outcomes. Product strategists need to understand the value of this work and ensure it gets prioritised. Many technical leaders need a better appreciation for the value of sprinting towards product-market fit in the early days of the company, and businesses need to transition away from this approach before technical debt becomes insurmountable (with ample appreciation for how difficult this transition is). 

Technical debt is another reason to keep the scope of your product very narrow until you achieve product-market fit. The less broad and complex your product is, the less technical debt you'll accumulate. Catching up on your under investment in technical foundations will be much easier. Don't expand until you can do it right.

Tags: advice, startups, technology

# Why confidence should be factored into ROI estimates

Comparing the _value of doing something_ to the _cost of doing it_ is the most common calculus for _Return on Investment_ (ROI), employed by many tasked with the prioritisation of work. The goal of this is to determine the _margin of value_ for various endeavours and prioritise them accordingly. This usually looks something like this:

```
Return on Investment = Benefit ÷ Cost
```

_Benefit_ is the expected return (e.g., _a new feature will bring $200,000 of new revenue_) and _Cost_ is the amount that must be invested to achieve the expected return (e.g., _15 hours of work at $100 per hour is $1,500_).

While this seems like a pretty reasonable and logical way to calculate the value of doing something, it comes with the dangerous assumption that we actually know how much value we'll get from the initiative and how much it will cost. Assumptions around both expected value and effort required are usually wrong, often dramatically. The outputs of algorithms like this can lead you astray if the inputs are incorrect, making prioritisation based on this method an exercise in futility. This is why teams should factor confidence into their ROI estimations, recalculate and reflect on ROI estimates after work has been completed, and assemble around long-term areas of focus where multiple hypotheses can be tested. 

A simple way to improve the algorithm for ROI is to include _confidence_ as a factor. You can do this by simply polling the team on how confident they are in both their _cost_ and _benefit_ estimations. This new algorithm might look something like this:

```
Return on Investment = ((Benefit × Confidence in the Solution) ÷ Cost) × Confidence in the Estimated Effort
```

This new equation is tempered by the confidence of the team, who might vote on confidence at the same time as they estimate the size of the work involved. We're penalising the expected benefit of doing the work with our confidence that the solution will bring the expected benefit (e.g., _if we are 50% sure our solution will bring us the expected $200,000 of new revenue, we lower our expectations to $100,000_). We are also penalising the entire ROI by our confidence in our estimate of effort. There is no single right way of doing this and you might want to tweak the algorithm to penalise the expected ROI in different ways.

By factoring confidence into our estimates of ROI, initiatives with a higher level of confidence are more likely to be prioritised over initiatives where the solution might need more exploration and the expected return needs to be better scrutinised. Highly effective teams will bring forward research and investigation (e.g., _spikes_) to improve their confidence in future work, before committing to risky initiatives packed with untested assumptions. Sometimes, teams might still decide to tackle work that they have low-confidence estimates for. Confidence factors are still useful in these scenarios because they provide a tool for teams to manage stakeholder expectations (i.e., _we know we're taking a big risk here, but we think it is worth it_).

Reflection is another valuable tool for teams looking to estimate ROI. Even seasoned teams can find it very difficult to estimate ROI in advance. Predicting the future is very difficult, and our best tool for improving our ability to do so is the _retrospective_. This is why it can be valuable for teams to re-estimate ROI after an initiative has been completed and the _benefit_ and _effort_ inputs are known. Regularly reflecting on whether a solution worked and what made our assumptions around value and cost accurate or inaccurate will make future estimates more reliable, even if only by better tuning our confidence in our estimates.

After a few cycles of estimating both value and effort, and reflecting on actual outcomes, many teams come to a common conclusion: big problems are rarely solvable through a single chunk of effort. This is why long-lived teams that are consistently focused on owning areas of improvement for the long term are usually the most successful. This is an alternative to bouncing between unrelated projects that attempt to solve diverse problems, which may only ever provide a degree of success, and is one major reason why hyper-focused products tend to win. _Many solutions to one big problem_ trumps _many solutions to many problems_, because the cost of failure is lower and the compounding value of effort invested is more easily realised.

Tags: advice, startups, operations

# Great products are opinionated

Is your product trying to be too much for too many people? By honing in on a more opinionated approach to the problems you solve, you might find it significantly easier to prioritise your roadmap, deliver software, and sell your solution.

While this is a word that often comes with negative connotations, I believe that great products, particularly in the B2B world, are usually very opinionated. They come with a strong view of how they should be used, and how the problem they are solving should be solved. These products differentiate themselves from the herd and disrupt incumbents by _doing things differently_. Many B2B SaaS products are simply automated workflows built from the opinionated views that _you should solve that problem in this specific way_.

There is a tension between this idea and the principle of _building flexibility into your product and technology_. Flexibility can enable you to more easily pivot your product direction and repurpose your technology, and strategically building your product in a flexible way can help you to maximise your options for the future. But, it can also severely limit the product you build by keeping you in a vacillating state. When building great products and technologies, there are many scenarios where you need to go all in. Otherwise, you end up trying to do too much for too many businesses. 

This is especially true for the many SaaS products that require a degree of configuration or customisation (usually facilitated through professional services) during the onboarding phase. Many businesses building products like this encourage their prospects to come to them with a list of requirements that they will try to configure their product to satisfy. This usually leads to extreme diversity in how a product is used and configured, making the product expensive to support and slow to adopt. It also often leads to poor customer outcomes because it encourages users to configure the product in novel ways that the product was not designed around — _just because something is feasible does not mean that it is desirable_. Opinionated products are sold differently — they know what problems they solve, and they are opinionated about how they solve them. Customers are encouraged to bring _problems_ to the vendor (not preconceived solutions or feature requests), and the vendor provides opinionated solutions to these problems. Sales teams confidently pitch these solutions as the best way to meet customer needs. The effort required to implement the product is low because _it has been done before_ and the entire process can be either automated or templated. Novel solutions are avoided, and customers who need something custom go elsewhere. This standardisation of user experience and configuration is what makes so many B2B SaaS companies so valuable: they can achieve very good gross margins by selling the same solution to many businesses.

Much of this comes down to one of the major differences between professional services businesses and product businesses. While professional services businesses are building custom solutions to solve problems for their clients, product companies are building a single solution for a large swathe of the market. The one-size-fits-all approach is what makes product companies so much more valuable than professional services companies because this model is much more scalable. If you look under the hood of many B2B SaaS companies, they actually look a lot more like professional services companies that've built a degree of standardisation into their solutions through some product development. Many still have long sales cycles, diverse and complex implementations for each unique customer, and poor gross margins for their recurring revenue (i.e., _they depend too heavily on implementation/professional services revenue and the recurring revenue side of their business is not self-sustaining_). An over reliance on professional services often causes a bottleneck in the onboarding process, which stunts the growth of the company.

This might sound like an environment where sales teams are saying _no_ to customers a lot more than they are saying _yes_, but opinionated products are actually easier to sell. Great B2B products come with their own philosophy on how big problems should be addressed. Philosophies are easier to communicate and spread around organisations and markets than feature lists are. Salespeople typically find it a lot easier to understand and sing from this type of solution-focused hymn book, rather than a checklist of features, and they become trusted advisors in the eyes of prospects. And, when selling a product with a specific worldview and differentiated approach, it's a lot easier for sales and marketing teams to challenge competitors. Challenger brands aren't better because of specific features but rather the broader approach they take: they are better because they do things differently (*e.g.,* [Notion has a great page challenging incumbent Confluence](https://www.notion.so/confluence)). Great products can become synonymous with the philosophies they espouse, even becoming movements (e.g., _Roam Research comes to mind as a great example of a product that is synonymous with the movement it is currently spearheading_).

Another benefit of building an opinionated product that supports a limited set of use cases is the technical simplicity that comes with this. Every configuration option that you introduce into the product introduces technical complexity. It is a lot slower for developers to commit new code products with a large number of configuration options and use cases. Automated testing is more difficult, and edge cases grow exponentially as you add configuration options. Ultimately, customisable software is slower to develop and harder to maintain in the long term.

Tags: advice, startups, strategy

# The case for personal wikis and professional journaling

A trend I've noticed amongst the most effective people I know is that many of them are keeping a _personal knowledge base_ (which you could also call a _personal wiki_, a _professional journal_, or many other things). This is clearly a trend beyond my immediate network, given the glut of new tools at least partially designed with this purpose in mind (e.g., _[Notion](https://www.notion.so/personal), [Craft](https://www.craft.do), [Clover](https://cloverapp.co), [Roam Research](https://roamresearch.com), or [Obsidian](https://obsidian.md)_). I started my personal knowledge base in 2010 (using Evernote) and it has been incredibly valuable to me throughout my career, so it has been great to see this trend take off recently.

People have always taken notes at work — this is not new. What _is_ catching on, though, is the idea of creating, revising/maintaining, and structuring these documents with long-term utility in mind. For most people, the notes they take throughout their careers are intended for temporary use (e.g., _to ensure you don't forget decisions made in a meeting_). My peers in the _personal wiki club_ are creating long-lived documents on topics, and playbooks for situations, that will come up again in the future. Notably, they put effort into making them easy to rediscover and maintain.

Work is repetitive. Between days, weeks, projects, and jobs, most people will tackle the same, or very similar, problems and tasks multiple times. In the professional services industry, service providers embrace standardisation to improve the ROI of their work. For example, agencies tasked with building e-commerce websites rarely start from scratch — they bolster their process with templates and reusable snippets of code that reduce the need to re-invent the wheel every time they tackle a similar project. Professionals should think about their jobs this way: as an individual providing a service to a client (i.e., _your current employer_). If you are frequently carrying out similar tasks across different projects, it is common sense to standardise (and potentially automate) this work. By creating and maintaining personal documentation on the various problems you've tackled, you can build a playbook for the next time you have to tackle a similar problem. These playbooks should follow you for your entire career. The _secret sauce_ for your effectiveness and success. 

Throughout its lifecycle, a company typically builds value in its revenue, partnerships, employee base and intellectual property, and all of these aspects are reflected in its valuation. Throughout your career, the value of your labour will also increase. This is due to the accrual of value in your experience, your network, and aspects of your professional identity. Experience will give you more knowledge and better intuitions for what to do in various situations, and keeping a personal knowledge base makes your experience much more tangible, explicit, and accessible. This will make you a more valuable employee. You could think of your knowledge base as the intellectual property that you build throughout your career[^1]. People with privileged and well-documented experiences could have a highly valuable knowledge base that makes future success more attainable. 

Additionally, while it may be a little too cliche to bother pointing out, writing is a critical part of the learning process. Honing in on a specific opinion on a topic is most easily done through writing, and this process will help you to fully understand what you are learning. One added bonus of this: learnings and ideas that are solidified in text are much more easily shared. If you're trying to understand something complex, I suggest you try by writing an explainer for yourself, and keep it somewhere you can easily access in case you learn more, change your mind, or need to tackle this problem again.

[^1]: The contents of your knowledge base should be _your_ intellectual property (IP), not the IP of any of your employers. Don't keep data that does not belong to you.

Tags: advice, startups, misc

# Crypto is creating an angel investing market for arts and culture

Thanks to artists like [Beeple](https://www.theverge.com/2021/3/11/22325054/beeple-christies-nft-sale-cost-everydays-69-million) and projects like [CryptoPunks](https://www.larvalabs.com/cryptopunks), NFTs have been the main character of crypto news in 2021. This has led to an avalanche of NFT sales by artists and celebrities all over the world. Despite the heavy focus on people with clout cashing in on their social capital, I think NFTs will have an even bigger impact on artists emerging today.

NFTs (non-fungible token) at a glance:

- NFTs are entries of data stored on a blockchain.
- The tokens that store data like this are therefore unique and _non-fungible_.
	- Traditionally, tokens (i.e., _coins_) on blockchains have been fungible (i.e, _interchangeable_). So, they work like currency, where there is no meaningful difference between two different notes of the same denomination. There's no value difference between owning two different individual Bitcoins.
	- Because data is stored within a _non-fungible token_, they are not interchangeable with other tokens — they are unique! There could be a significant value difference between two _non-fungible tokens_.

One common criticism of NFTs is that, as they are simply data in a public database (albeit a new type of database), they can easily be copied, reproduced, and created without permission. Why would you buy something anyone can copy? People making this criticism are missing the value of NFTs entirely. NFTs are more comparable to a certificate of ownership and authenticity than they are to a physical piece of art. When buying a [Rothko](https://www.artsy.net/artist/mark-rothko), art collectors do not lament how easily they could be reproduced. This is because the value of owning a Rothko is _not because it looks like a Rothko_, but rather because it is (provably) a Rothko! Through NFTs, blockchains provide a more robust record of ownership than ever before (there is no reason why NFTs couldn't be used to represent ownership for physical art, too). Meanwhile, reproducibility will inevitably only get easier as the world becomes more digital — this makes a reliable record of ownership even more valuable, not less. 

A thriving art market, with proof of ownership bestowed by trusted marketplaces, has existed for a very long time. On the surface, the technology behind NFTs may seem like an incremental improvement to this system. In my view, NFTs have already significantly changed the future of the art market, though. They've done this by making the ledger of art ownership available to artists no matter their career stage, rather than just those who can draw the attention of the likes of Sotheby's. This means collectors can invest in artists from all over the world at the start of their careers rather than only after they make it big. This new market of early-career (and therefore cheap) art also opens the collector market to anyone.

The ability to easily and safely find and purchase art from artists who are only just starting their careers is creating a huge opportunity for collectors of all calibres. By investing in an artist at the start of their career, you can achieve much more ambitious long-term capital gains than ever before. Taking a risk on an emerging artist could eventually pay off massively. This essentially creates an angel investing market for art and culture. This angel investing market will strongly favour those with a good eye for what will eventually become very successful, which probably means other artists. This will empower artists to become art collectors, reinvesting the capital they've made from their art, into the next generation of artists. This will look a lot like the world of startup angel investing.

Essentially, the world of art investment will look much less like the ultra-rich investing in already-famous artworks, and more like everyday people and artists re-investing their capital in the next generation of artists. The ultra-rich will continue to acquire their fair share, of course.

Lastly, another feature of blockchains is that they are programmable. This means new rules can be built into blockchain-powered markets. Artists choose where they sell their work, so they can choose a rule set that looks out for them. For example, OpenSea (like many other NFT marketplaces) [allows artists to configure royalties when creating their NFTs](https://support.opensea.io/hc/en-us/articles/1500009575482-How-do-royalties-work-on-OpenSea-). NFTs with royalties configured will pay a commission for any future sale to the original artist. This means if you sell your artwork for a small amount today and later become very successful, you'll continue to earn royalties from future sales of your now highly sought after artwork. This, and other future marketplace innovations, will create a more artist-friendly market.

Tags: advice, startups, crypto

# Embrace uncertainty through a “just enough” approach to product strategy

A common anti-pattern in the world of software development is the over-operationalisation of the research and development process. In moving away from traditional ways of working, companies will spin up long-lived teams, working to sprint cycles, but still find a way to cram an inordinate amount of upfront planning into the system, causing a significant amount of waste. This can feel like a big step in the right direction but often comes with very little benefits compared to the old way of working, as the way the team works doesn't change.

Teams should embrace uncertainty and experimentation by implementing a _just enough_ approach to strategy and ideation.

## “Just enough” roadmaps

Roadmaps should not be long lists of thoroughly defined features and tasks. As great as it would be to have a bulletproof, long-term plan for your business, this is rarely achievable. Instead, backlogged initiatives should be less thoroughly defined the further they are from implementation. This ensures that:

- **Cost to pivot.** The cost to pivot is much lower when distant roadmap items are thought of as future opportunities and ideas rather than pre-defined scopes of work scheduled for future completion. New learnings often suggest that you should abandon a large chunk of your planned roadmap in favour of a new set of initiatives.
- **Avoid sunk-costs.** Time spent detailing future work that may never actually be delivered is unrecoverable. This time could be better spent on other work. Additionally, individuals who've invested big chunks of time in scoping features will be biased towards having those features built. This could lead to inertia in situations where agility (i.e., _ability to pivot_) is critical.
- **Pre-defined scopes are usually bloated.** When the planning process is  decoupled from the delivery process, one's eyes can be bigger than one's stomach. This usually leads to unnecessarily large scopes of work for the real problem at hand. [Outputs are then prioritised over outcomes](/post/focus-on-outcomes-over-outputs).
- **Manage expectations.** Gluttonous, pre-defined scopes of work, have a way of getting around. Internal and external stakeholders get attached to specific implementation details, and any future [cutting of scope](/post/in-defence-of-cutting-scope) leads to disappointment. By making future work explicitly tentative and broad, stakeholders can be focused on the _problems being solved_ rather than the bells and whistles.
- **Encourage creativity.** Upfront planning is usually done in a silo by product managers and designers. Even if they try to be as consultative as possible, the engineers who will eventually execute the scope of work are rarely available to sink their teeth into the scoping process for work that won't be tackled any time soon. By leaving planning until much later, engineers can be much more involved in the process. This will not only lead to better outcomes in the short term, but it will also foster a more innovative environment where engineers are very engaged in the _why_ and _how_ of what they build (as opposed to simply churning out code).

## You still need a plan

It's still important to know what's next and to have a North Star for your product. Here are some tips for providing direction without being overly wasteful or prescriptive.

- **Start with a simple but ambitious mission.** Everything your company tackles should be tied to a one-sentence mission that is easy to remember and understand. For example, Google's mission is _to organize the world’s information and make it universally accessible and useful_.
- **Set a vision for the upcoming period.** This could be a goal for the next couple of years or more and should represent a major milestone or step-change for the company. For Google, it might be to _become the #1 generalised search engine on the internet_. I like to scaffold these goals with specific success measures (e.g., _customer count, growth rate, NPS_). Again, this should be succinct, easy to remember, and easy to understand.
- **Outline your strategy.** Enumerate the high-level initiatives that you believe are required in order to achieve the vision. [I like to define these as problems to be solved](https://fastertim.es/post/defining-initiatives-with-at-outcome-mindset). If the problem isn't well-defined, and relevant to your vision, it probably doesn't belong in your strategy.
- **Solution near-term initiatives.** While most initiatives should simply represent problems you want to solve in the future, your team may require some guidance to determine how a problem should be tackled. If this is the case, some solutioning should be carried out for initiatives that you expect to tackle soon. A [definition of ready](https://www.likelystory.me/care-about-definition-of-ready/) for initiatives can help this process. 

Using the framework above, the more near term a piece of work is, the more clearly defined it is. The mission is broad, the vision is less so, the strategy has explicit steps (but with open-minded solutions) and upcoming initiative have some high-level solutioning. The goal is to ensure the company has direction, and that when an initiative is picked up it is ready to be ideated and delivered by the team.

I typically leave greater levels of fidelity to the team (e.g., _epics_, _stories_, _spikes_, and _tasks_), but these should also be defined only when required.

## Tactics

The scoping and decision-making process can be greatly simplified if common decisions can be standardised. A high level of standardisation will make planning more rapid and therefore reduce the amount of time required to scope upcoming work. Conversely, standardisation will reduce creativity and out-of-the-box thinking, so it is absolutely possible to go too far.

- **Design principles.** One way to simplify the decision-making process is to be explicit about what is important to the team. This can be done through designs principles (both UX and technical). Example design principles include [API-first](https://swagger.io/resources/articles/adopting-an-api-first-approach/), [mobile-first](https://xd.adobe.com/ideas/process/ui-design/what-is-mobile-first-design/) and [dogfooding](https://www.techopedia.com/definition/30784/dogfooding).
- **Technical patterns and foundations.** Teams will likely face the same technical problems multiple times. By building internal foundations (e.g., SDKs, automation, and infrastructure-as-code) upfront, you can reduce future decision making and development effort.
- **Design patterns.** Teams will also likely face the same user experience challenges multiple times. Building design guidelines and a component library can significantly simplify the user interface design process and enable teams to get straight to execution.

## Supplement planning with research and experimentation

A _just enough_ approach to strategy and ideation can feel a bit like shooting from the hip. This is especially true when future initiatives have a significant level of uncertainty around implementation. In scenarios where future initiatives feel especially daunting because the solution is not obvious, [research and experimentation should be embraced](/post/use-experimentation-to-become-more-ambitious). Teams can bring forward experiments and research (e.g., _technical proof of concepts_, _customer research_, _UX prototypes_) relevant to future initiatives in order to gain some early confidence in how a problem can be tackled.

Tags: advice, startups, product

# DAOs, design-by-committee, and the future of online organisations

The world of work is rapidly migrating from physical space to the internet and this newly dominant medium for work is going to significantly change how we structure society. This may sound dramatic, but it is inevitable that industrial-revolution era systems, legislations and structures will eventually be superseded.  I think, in the crypto community, we're already seeing the structures of the future emerge.

The world today looks very different to the world in the 1970s when the first LLCs were established to adapt the corporate world for globalisation. In the crypto community, a new organisational structure has been adopted to cater to the brave new world of distributed collaboration: the DAO (Distributed Autonomous Organisation). Put simply, DAOs are internet-native organisations, orchestrated by code on a blockchain, designed to enable a distributed membership to democratically govern their pooled resources. DAOs can represent commercial endeavours (i.e., _companies_), non-profit initiatives, social clubs, and more.

> Thanks to the glut of acronyms and arcane terms, DAOs can seem a lot more complicated than they really are. Just think of them as a new type of business structure alternative to partnerships, sole traders, companies and LLCs, enabled by some pretty simple technology.

At a glance:

- **DAOs are democratic.** Membership is granted by the commitment of capital or work. Members can then raise and vote on proposals, like a board of directors.
- **DAOs are distributed.** As an internet-native organisational structure, DAOs enable (potentially even anonymous) people from around the world to collaborate. I believe this location-agnostic approach is the biggest benefit that will lead to adoption.
- **Members pool and invest their resources.** A DAO is like [a group chat with a bank account](https://twitter.com/awrigh01/status/1383423710569197577). Participants vote to decide how funds (which exist as cryptocurrency) are spent/invested.
- **DAOs are regulated by code.** All organisations are managed against contracts and regulations, but compliance with these rules is reliant on the good faith of members. DAOs augment their _shared bank account_ with code ([smart contracts](https://www.investopedia.com/terms/s/smart-contracts.asp)) that ensures funds are only utilised when the pre-defined voting conditions are met. This enables DAOs to operate in zero-trust circumstances (e.g., _collaborations with strangers from all over the world_).
- **DAO regulations can be patched.** DAOs have the capacity to make changes to existing systems by providing a mechanism to replace any part of the system that is not working or is a security risk.

> Starting an organisation with someone that involves funding and money requires a lot of trust in the people you're working with. But it’s hard to trust someone you’ve only ever interacted with on the internet. With DAOs you don’t need to trust anyone else in the group, just the DAO’s code, which is 100% transparent and verifiable by anyone.
> 
> — [Decentralized autonomous organizations (DAOs)](https://ethereum.org/en/dao/), Etherium.org.

Contracts are ambiguous, argued by lawyers and discerned by judges. Smart contracts, however, are completely unambiguous — unlike legalese, code is interpreted one way only. This is the innovation that enables truly distributed organisations. If you trust the code that undergirds your organisation, the amount of trust you need in your collaborators is significantly reduced. Obviously, code comes with its own risks: code can have bugs and security flaws and [this has caused serious problems for DAOs already](https://www.gemini.com/cryptopedia/the-dao-hack-makerdao).

One common criticism of DAOs by the old guard of business is that truly democratic organisations (particularly ones with a very large voter base) will suffer from the many shortcomings of [design by committee](https://en.wikipedia.org/wiki/Design_by_committee). If in the future, you're imagining the average DAO will have a very large pool of distributed members, I think this is actually a pretty reasonable criticism. While broad democracy is a great framework for governing some types of organisations (I imagine this will have phenomenal results in the philanthropic space), I would argue that most great companies succeed as a result of the outsized influence of specific contributors and operators who possess the right skills and experience to solve a specific problem. Absolute organisational democracy would dilute the influence of these people and ultimately put DAOs at a disadvantage against traditional organisations.

This is why I think, in the future, many DAOs will end up having a small, selective membership, resembling a corporations board of directors. And, while many believe DAOs will liberate organisations from the tyranny of centralised leadership (i.e., _executives like CEOs_), I believe many DAOs will elect to hire CEOs and executive teams. DAOs will also likely lead to more generous and transparent [ESOPs](https://www.investopedia.com/terms/e/esop.asp) for employees.

Is anyone eager to [start a DAO and buy some coal mines](https://marginalrevolution.com/marginalrevolution/2021/10/be-green-buy-a-coal-mine.html)?

Tags: advice, startups, crypto

# Defining the role of a software engineer

_**Below is a playbook I've used to describe the responsibilities of a software engineer for hiring and professional development purposes.**_

Software Engineers are responsible for delivering value to our customers and the business within our product development environment where:

* Outcomes are the focus, rather than outputs.
* Product teams consist of individuals with diverse skills, because no individual covers all bases.
* Ownership between teams and individuals is clear.
* Teams can make time for experimentation to reduce the risk around upcoming work. This helps teams to become more ambitious without jeopardising outcomes.
* Reusable patterns are valued and utilised.
* Teams work backwards from a desired outcome or goal rather than forwards towards a nebulous end state.
* Teams are high-leverage, meaning they've utilised reusable patterns and their body of research to achieve greater outcomes with less effort.

## Responsibilities

All Engineers:

- **Deliver high-quality software.** Business-as-usual for Engineers is the delivery of solutions through high-quality contributions to our codebase. They do this by embracing our established reusable patterns and tooling, test automation, documentation, and collaboration with their peers. 
- **Explore solutions with your team and stakeholders.** It's not enough to simply execute — Engineers need to have ownership over their solutions. This includes participating in refinements, solutioning, and creating initiatives, user stories and tasks. 
- **Engage in the _continuous improvement_ of your team.** Every Engineer belongs to a team, and every team needs to constantly reflect on performance and effectiveness. In order for teams to self-improve, every member needs to be engaged in reflection (e.g., _through reviews and retrospectives_) and self-improvement.

Senior Engineers:

- **Evolve our reusable patterns and tooling.** To be high leverage, teams must rally around standardised patterns and tools, to avoid having to _re-invent the wheel_ every time they tackle a common problem.
- **Evolve our ways of working.** Senior Engineers must champion software development practices that promote outcomes (over outputs) and work with their team to improve the operations of the team. 
- **Technical architecture/planning.** While all Engineers contribute to the technical architecture of our product when developing new features, Senior Engineers (and above) are expected to have a more long-term, cross-initiative opinion on our future architecture. When solutioning an initiative, they must consider other future initiatives and our broader technical direction, to ensure we're working towards our goals.
- **Mentor the team.** Senior Engineers (and above) should take responsibility for the success of others in their team. 

Tech Leads:

- **Lead the refinement and solutioning process.** Tech Leads are responsible for their teams solutions. This includes leading refinements, solutioning, and creating initiatives, user stories and tasks. 
- **Manage our upstream dependencies.** Our software is built with various upstream dependencies that need to be selected and maintained. Tech Leads should guide this process.
- **Manage our reusable patterns and tooling.** Tech Leads own the roadmap for pattern and tooling enhancements, which should be tied to our technical vision.
- **Manage our ways of working.** Tech Leads are responsible for the _way of working_ for their team.

Tags: advice, startups, people, playbook, product