When You Can Build Anything, How Do You Decide What to Build?
Every engineering team eventually faces this question, and fifty years of business theory offer some guidance on how to answer it.
When You Can Build Anything, How Do You Decide What to Build?
Every engineering team eventually faces this question, and fifty years of business theory offer some guidance on how to answer it.
Stauffers of Kissel Hill
The Burden of Infinite Possibility
In November 2012, Tiny Speck’s team met in their Vancouver office, with colleagues joining from San Francisco. The room was quiet, everyone sensing bad news. “This is a horrible day, and I’m so sorry,” Stewart Butterfield said. His forty artists, engineers, and designers knew right away: Glitch, the online game they had spent years building, was over.
What happened next is a valuable lesson in product history, not because of the outcome, but because of the decision behind it. Between late 2012 and early 2013, Butterfield told investors that Tiny Speck would shift to enterprise software. The team’s internal messaging tool, which they used to coordinate across Vancouver, San Francisco, and New York even as other projects ended, would become their new product. They called it Slack.
Less than two years after the pivot, Slack had 60,000 daily users, 15,000 paid seats, and had closed a funding round at a billion-dollar valuation. Salesforce would later acquire the company for $27.7 billion.
The story gets told as a luck narrative, a pivot romance, a right-place-right-time story, a framing that misses the harder thing Butterfield did, which was to choose correctly under conditions where almost any choice could have been rationalized. When a team can build many things well, choosing what to build becomes the highest-leverage work a leader does, each wrong decision spending down the most finite resource available, not money but human attention, on precisely the wrong problem. Business schools and sprint planning meetings have been wrestling with this question for fifty years without fully solving it.
What Business Schools Teach About Choice
The frameworks that top MBA programs teach for evaluating opportunities share a common structure: assess what the external world is offering, then determine whether the organization can exploit it. NYU Stern describes this as “the alignment of a firm’s internal resources and capabilities with external market opportunities to sustain an advantage relative to rivals,” a formulation that captures the basic shape of every strategy course taught at every school, whatever terminology the faculty prefer. Harvard’s case method, five hundred cases across two years, builds pattern recognition under ambiguity. MIT Sloan emphasizes analytical precision and data-driven decision-making; its curriculum is designed around the assumption that good numbers, rigorously interrogated, are the best antidote to bad intuition.
Business schools teach these frameworks for good reason, and the canonical ones are worth knowing.
SWOT analysis forces a team to be honest about both what the organization can do and what the market is doing, with its four quadrants holding in tension the internal and the external, the present and the possible. Its weakness is structural: it produces a picture, not a direction, showing you where you stand without telling you where to go.
Porter’s Five Forces asks a prior question: before asking whether you can win, is the market worth entering? The threat of new entrants, buyer and supplier power, the availability of substitutes, and competitive intensity together determine whether a given industry is structurally attractive, independent of any individual firm’s capability, making it a filter rather than a map.
The BCG Matrix, developed at the Boston Consulting Group in the 1960s and still standard curriculum, addresses portfolio allocation (which bets to feed, which to harvest, which to kill), giving organizations a shared vocabulary, stars and cash cows, question marks and dogs, for the conversation most find hardest: where to stop investing.
Ansoff’s Matrix maps the risk profile of different growth directions, with market penetration, product development, market development, and diversification each carrying different organizational demands and different probabilities of success; the distance from the top-left corner corresponds roughly to the likelihood that things will go wrong.
These frameworks illuminate competitive position, market attractiveness, and internal capability. None of them requires a team to stand in the shoes of the person they’re trying to serve and understand what that person is actually struggling with, a structural limitation that practitioners have been bumping into for decades, and that one Harvard professor spent the better part of twenty years trying to correct.
The Innovator's Dilemma
In 1997, Clayton Christensen published The Innovator’s Dilemma and made an argument that was, at the time, uncomfortable: the companies most likely to be disrupted weren’t the badly managed ones. They were the well-managed ones: companies that listened carefully to their best customers, invested in product improvements those customers asked for, and allocated capital to opportunities with clear returns, doing everything right and still ending up in failure. Good management, Christensen argued, was often the proximate cause of strategic failure, because incumbents were so focused on existing customers that they became blind to the needs of customers they didn’t yet have.
His later work formalized that finding into a theory, developed across Competing Against Luck (2016) and anchored in a deceptively simple claim: customers don’t buy products; they hire them to accomplish something. The unit of analysis isn’t the demographic segment or the product category; it’s the job. As the Christensen Institute describes it, Jobs to Be Done theory “goes beyond superficial categories to expose the functional, social, and emotional dimensions that explain why people make the choices they do.”
The milkshake example, now the theory’s most-cited illustration, began with a fast food chain trying to improve sales. Standard research, surveys, focus groups, and segmentation produced nothing useful, so Christensen’s team observed instead, asking not what people wanted in a milkshake but what they were hiring a milkshake to do. For morning commuters, the job had nothing to do with flavor. They needed something lasting a twenty-minute commute, fitting in a cup holder, requiring one hand, keeping them from being hungry by 10 am, their real competitors not other milkshakes but bananas (gone in three minutes) and bagels (two hands, left crumbs). Asking customers directly what would improve the product, Christensen wrote, was “a fast way to arrive at the wrong place.”
The highest-value opportunities, under this framework, are jobs that matter to customers but are currently handled badly. Over-served jobs, where products already do more than most customers need, are vulnerable to disruption from cheaper, simpler alternatives. When a team builds something for a job that doesn’t exist in any real customer’s life, no amount of execution quality saves them, a point Christensen illustrated with the Segway: well-capitalized, technically impressive, built by smart people, solving a problem that nobody was actually hiring anyone to solve.
Slack and the Job Nobody Had Named
Butterfield’s team in late 2012 had an advantage that the standard strategic frameworks would not have surfaced: they were their own customer. Three and a half years of using their internal messaging tool daily, building it against their own real frustrations with coordinating across time zones and cities, had given them something more useful than market research: direct, lived knowledge of the job.
The job was real-time coordination among small, distributed teams, the fast and informal exchange of context that makes collaboration feel like collaboration rather than correspondence. IRC existed but required technical setup. Email was formal and asynchronous. Meetings were expensive and left nothing behind. The gap between what was available and what the team needed was visible to anyone who had actually tried to build software across three cities.
What separated this from other post-mortem pivots was what Butterfield did before writing code. In a Masters of Scale interview, he described a pitch deck assembled before building had begun, containing the pricing they would ultimately launch with, the product vision, and the marketing approach. “Everything was preset, and we didn’t have to change it,” he said, “because we had three-and-a-half years of practice, finding product-market fit for our market-of-one team.”
Knowing the job clearly enough to set the price before building the product kept every subsequent decision consistent, the team never having to relitigate what they were building or why. Teams that build first and try to articulate the job later are always fighting that sequence, the absence of early clarity compounding into the product itself, visible in the features that don’t quite fit, the onboarding that can’t quite explain itself, the retention numbers that arrive as a surprise.
What Engineering Teams Actually Use, and Why RICE Works
The MBA frameworks above are powerful. They’re also expensive, requiring research infrastructure, time, and organizational will that most engineering teams don’t have on a sprint-to-sprint basis. But the questions those frameworks are trying to answer don’t disappear at smaller scale. They need different tooling.
RICE was developed at Intercom by Sean McBride, a product manager who watched the company repeatedly deprioritize high-reach opportunities in favor of features that had high individual impact but reached very few users. The framework scores any initiative on four dimensions:
- Reach: How many users will this affect in a given time period, measured in real users per quarter (not “enterprise customers” or “the market”).
- Impact: How much will it move the needle for each affected user? Intercom uses a five-point scale: 3 for massive impact, 2 for high, 1 for medium, 0.5 for low, 0.25 for minimal.
- Confidence: How certain is the team about these estimates? 100% means real data. 80% means reasonable evidence. 50% means gut.
- Effort: Person-months across all contributors: engineering, design, QA.
Formula: (Reach × Impact × Confidence) ÷ Effort
The output is a number representing total impact per unit of time worked, the team sequencing work from highest score to lowest.
The Confidence dimension is where RICE does its most useful work, requiring the team to separate what they know from what they believe, a distinction that sounds obvious but disappears quickly under the pressure of a planning meeting. McBride was direct about it: “A project with low confidence might be one where all you have is a quick sketch on a whiteboard and a gut feeling. Another way to use the RICE score is as a framework for looking at how to develop ideas. Do you have an idea that you think could have huge reach and impact, but the confidence is really low? If yes, then what type of user research or technical exploration could your team do to learn more and raise the confidence level?”
A low confidence score isn’t a reason to kill an idea; it’s a diagnostic, a signal about what work needs to happen before a build decision can be made responsibly.
RICE works well at the quarterly roadmap level. For sprint-level decisions, ICE (Impact, Confidence, Ease) is faster and requires less data. For portfolio-level sequencing across teams, WSJF introduces cost of delay, the economic value lost by waiting, asking a more senior question: not just what’s most impactful, but what becomes less valuable the longer it sits undone. Teams get more from layering these frameworks by decision altitude than from choosing between them.
Facts
Underneath the frameworks, there are a few things about value that behave less like strategic principles and more like physical constants, holding across industries, company sizes, and eras, resistant to the usual moves of strategic reasoning.
Nobody ever wants it to be slower. Speed has no exceptions on record: no customer has ever complained that something happened too fast, no product has ever lost users because it was too responsive. Every additional millisecond of latency is friction, and friction is where users reconsider. Speed isn’t a feature; it’s the substrate everything else runs on.
Nobody ever wants it to be more expensive. Premium markets exist, and customers will pay more for more value, but what they will not do is feel good about paying more for the same value. Cost functions as a proxy for respect, and customers are consistent about noticing when they’re not getting it.
Nobody ever wants it to be more complex. Complexity accumulates without anyone choosing it, arriving as the residue of a thousand individually reasonable decisions, each feature addition making the product slightly harder to understand, slightly more expensive to maintain, slightly more likely to fail in a new way, the total weight invisible in any single planning meeting but legible in the product over time. The products that hold up tend to be the ones that resisted adding things, not because the teams lacked ambition but because they understood that restraint and quality are, at scale, the same thing.
These three aren’t a checklist so much as a stress test. When proposed work makes the product slower, more expensive, or more complicated to use, the burden of proof for building it is high, a burden that should be met with customer evidence, not internal enthusiasm.
What Customer Obsession Actually Requires
“Customer obsession” has been repeated in enough all-hands presentations that it now functions mostly as atmosphere, a phrase that signals orientation without requiring it. The actual practice is harder than the phrase suggests, requiring something most teams resist: a sustained willingness to be wrong about what customers want.
Christensen’s JTBD research found repeatedly that customers struggle to articulate their real needs beyond what they can already imagine, describing symptoms rather than causes, asking for better versions of existing solutions rather than different ones entirely. As he explained in an interview, the job is always defined by circumstance as much as goal: “a customer is looking to achieve something that she has been struggling with, and the circumstances in which she is trying to achieve that matter in how she’ll try to solve that struggle.” A well-defined job should carry functional, social, and emotional dimensions, which is “very different from the traditional marketing concept of ‘needs’” because it demands a specificity about what you’re solving for that demographic research rarely reaches.
The right research methodology follows from that distinction. Asking customers what they want tends to produce answers describing better versions of existing solutions, the customers’ imagination bounded by what they already know. Watching customers work, observing where they get stuck, where they reach for workarounds, where they give up, produces something more useful: a picture of the job and the gap between how it’s currently done and how it could be done.
The failure mode Christensen kept returning to is a team building against what customers say rather than what they need, the two looking identical in a planning meeting and diverging in the market, usually around the time the retention numbers come in.
Butterfield’s team had the unusual advantage of being their own users, the job legible to them without research. That shortcut isn’t always available, and when it isn’t, getting into the customer’s context before writing code is not the setup for the work: it is the work.
The Decision Is the Product
The question this article started with isn’t technical, and it isn’t strategic in the portfolio-management sense. It’s a question about what a team understands about the people it’s trying to serve, and how honest it’s willing to be about the limits of that understanding.
SWOT forces honesty about capability, Porter, about whether the market is worth entering, Jobs to Be Done about what the customer is actually trying to do, and RICE about how much the team knows versus how much it believes. The laws of speed, cost, and complexity force honesty about whether proposed work is adding value or adding weight, a question that looks different depending on whether you’re asking it from a boardroom, a strategy retreat, or a sprint planning meeting, but that resolves, in each setting, to the same thing.
Butterfield’s team didn’t get lucky. They got clear, knowing the job, having already built something that did it, and articulating the product before committing the team to building it. That sequence, understanding the job, confirming the solution, then executing, is not a methodology unique to Slack or enterprise software. It’s available to any team willing to sit with the harder question before reaching for the easier answer.
By Joshua McDonald on April 7, 2026.
Exported from Medium on August 26, 2026.
Reader discussion