Answering and executing the question(s) "what do we build and how do we build it?" is an existential challenge for small companies.
What you build is probably more important than how you build it. But how you build it changes how well you can change it. And the what is going to change.
Uncertainty and risk are the abstract problems here. Will an onboarding email sequence increase the number of customers who convert to a paid membership? Do our users care about keyboard shortcuts? Should we hire someone new?
Dan McKinley's Boring Technology Club introduces the the idea of the Innovation Token, a metaphorical token that we spend on "our limited capacity to do something creative, or weird, or hard". A team has very few innovation tokens, and each token spent increases risk.
They increase risk because they make it hard to make a good guess about what will happen next. Good guesses are sometimes the only fuel that new companies and small engineering teams have. Longer-lived companies have experience or data to help.
The Shape Up methodology gets it right: we're making bets.
If you're an engineer you can make a bet more risky by building with newer technologies (frameworks or languages) or infrastructure (databases or cloud providers), relying on manual (not automated) testing or deployment, by prematurely optimising, by building in isolation from customers, and a hundred other smells.
A product person can increase risk by not knowing or understanding their customers, attempting to solve an over- or under-ambitious problem, by pricing things wrong (or not at all).
These types of risk are not separate[^1]
If you know your customer is extremely price sensitive, then building a $99/yr subscription model is going to have risk that even the most boring technology stack (IMO: MySQL, Rails, Bootstrap, Digital Ocean) cannot address.
Risk is risk. Risk from product (what) and risk from engineering (how) cannot be meaningfully separated once you take more than three steps backwards.
Your job is to reduce risk for yourself, your boss, or your company. Build software that reduces overall risk for the people who use it.
[^1]: I think we (I) separate the what from the how because they are often solved by a CEO and CTO. Just because a problem is solved by two people does not mean it is two problems.
See other articles