Silicon Valley Taught Me to Ignore Strategy. That Was a Mistake.

I’ve spent two decades building startups. Some were fairly successful, a few were acquired, but none became the kind of home run you dream about when you first move to Silicon Valley. Looking back, I can see plenty of reasons why. Some were bad decisions, some were circumstances outside our control, and some were things I simply didn’t understand well enough at the time. But I increasingly think we could have made better decisions if we’d approached strategy with a smidge more discipline.

For most of my career, I didn’t take strategy particularly seriously. Silicon Valley had taught me that strategy was something MBA students worried about while the rest of us were busy building companies. San Francisco has a strange relationship with business education. People routinely mock MBAs and dismiss traditional business thinking with advice like, “If you want to learn business, just start a business and talk to customers. There’s no faster way to learn.”

And I believed it. Why wouldn’t I? I was young, surrounded by smart people building interesting companies, and plenty of them shared the same philosophy. Many were successful. We were supposed to move fast, build products, talk to customers, and figure things out along the way. Writing a business plan was practically an admission that you didn’t understand how startups worked.

To be fair, the criticism of traditional business plans was often deserved. Most were elaborate narratives about how you intended to spend money, accompanied by a spreadsheet full of naive assumptions about how you’d eventually make it back. The revenue projections were almost always fiction, and the market analysis usually consisted of identifying a gigantic industry and assuming you could capture some tiny percentage of it. It was a terrible way to make decisions, and Silicon Valley was right to be skeptical.

But we took the criticism too far. We treated the failure of business plans to predict the future as evidence that strategic thinking wasn’t particularly useful. For someone like me, who came from engineering and loved building things, that was a convenient philosophy to believe. I could spend most of my time doing the work I enjoyed while assuming the market would eventually reward us for building the “right” product.

I Read the Books. I Still Didn’t Know How to Build a Strategy.

I’ve always enjoyed reading about strategy. Good Strategy/Bad Strategy, Good to Great, The Innovator’s Dilemma, and, of course, The Art of War, which is basically the literary equivalent of hanging a Che Guevara poster in your college dorm room.

These books gave me plenty to think about. They explained why companies succeeded or failed, and how leaders made decisions that seemed obvious once the results were known. Some of the stories were fascinating, although there’s a problem with studying successful strategies in retrospect. Once you know who won, it’s relatively easy to construct a convincing explanation for why they won.

What I struggled with was turning those lessons into a process. I could recognize a good strategy when an author explained one, but that didn’t mean I knew how to build one myself. The examples usually started with a leader who understood something about the market everyone else had missed. Great. How did they arrive at that understanding? What questions did they ask? What alternatives did they consider? And how did they know when they’d made the right choices?

Then I Read Playing to Win.

Roger L. Martin and A.G. Lafley’s Playing to Win fundamentally changed how I think about building strategy. Maybe the book really was that good. Maybe I’d finally reached the maturity to listen. Or maybe I’d spent enough years making mistakes, and watching other companies make similar ones, that I was ready to reconsider my assumptions. Maybe it was all three.

The book gave me something I’d been missing: an actual process for developing strategy. Five interconnected choices that force you to think carefully about where you compete, how you intend to win, and what your company needs to do to make those choices work. You move back and forth between them, challenging assumptions as you discover inconsistencies. This structure is particularly useful in discussions about strategy, which otherwise tend to become a mishmash of competing ideas, with everyone jumping between topics and hoping to reach some consensus.

I particularly like that the framework forces you to make choices. In startups, it’s easy to confuse ambition with strategy. You want to serve a huge market, build an amazing product, attract lots of customers, and grow quickly. Who doesn’t? The difficulty comes when you have to decide which customers you’ll pursue, which ones you’ll ignore, and what you’ll do differently from your competitors.

The five questions sound deceptively simple. Answering them requires considerably more thought than most of the business plans I avoided writing.

1. What Is Our Winning Aspiration?

The framework begins by asking what winning looks like. Who do we want to become, what are we trying to accomplish, and how will we know whether we’ve succeeded? The emphasis on winning is useful because starting a business means entering a competitive environment.

I still advise startups from time to time, and one of the first questions I ask founders is, “Who’s your biggest competitor?” Occasionally, someone tells me they’re doing something so innovative that they don’t have competitors. I take those founders a little less seriously, partly because I remember giving exactly the same answer myself. Oh, how naive we were.

The reality is that customers already solve their problems somehow. Maybe they’re using an existing product, maybe they’ve built something internally, or maybe they’re suffering through a manual process involving spreadsheets and a remarkable amount of human patience. Sometimes the problem simply isn’t painful enough to justify doing anything about it. Whatever the situation, you’re asking someone to change their behavior, and people need a compelling reason to do that.

Understanding why your competitors win is essential to developing a credible plan to beat them.

2. Where Will We Play?

The second question asks you to define where you’ll compete. Which customers are you targeting? Which markets or segments are attractive? What makes those customers worth pursuing? And which opportunities will you deliberately leave alone?

Startups tend to answer these questions casually. We create market-sizing slides showing enormous addressable markets, describe our target customers broadly, and start building. I’ve been guilty of this myself. It’s particularly easy when you’re developing technology that could theoretically serve lots of different people. Choosing a narrow customer segment feels like giving up opportunities.

But customers have different needs, constraints, budgets, alternatives, and buying behaviors. A product that works beautifully for one segment may be uninteresting to another. Without a clear target customer, it’s difficult to make good decisions about what to build, how to price it, or how to reach buyers.

One of my favorite examples from Playing to Win involves P&G’s development of a razor for the Indian market. Researchers discovered that many Indian men shaved using very little water, sometimes with just a small container, and that their routines differed substantially from those of American consumers. Those observations influenced Gillette’s product design and helped the company develop a razor suited to how customers actually shaved.

I love the example because it demonstrates how much you can miss when you assume customers experience a problem the same way you do. Engineers and founders are especially susceptible because we spend so much time thinking about products and technology. We can describe our product architecture in extraordinary detail while knowing surprisingly little about what happens in a customer’s life before they use it.

3. How Will We Win?

For much of my career, my implicit answer was that we’d build a sufficiently good product and customers would recognize its value. I came from engineering, loved building things, and believed product quality would ultimately determine who succeeded.

Unfortunately, markets don’t reliably reward technical superiority. Customers choose products for all sorts of reasons, including convenience, price, trust, familiarity, distribution, and switching costs. A technically impressive product can lose to a mediocre competitor that understands its customers and reaches them effectively.

I think a lot of technical founders, myself included, subconsciously imagine creating an incredible product and having people line up outside the door to buy it. Occasionally that happens. OpenAI’s early consumer adoption of ChatGPT is a remarkable example. But most companies have to work hard to make customers aware of their products, convince them a problem is worth solving, and persuade them to change their behavior. Even Apple spends enormous amounts on advertising and distribution.

Choosing how to win requires understanding why a particular customer would choose you over their existing alternative. What do they value? What will they pay for? How do they discover and evaluate products? Who makes the purchasing decision? How will you reach them? What makes your offer compelling enough to overcome the inconvenience and risk of switching?

These questions become uncomfortable when you’ve spent months building something you love. You may discover customers care far less about your favorite features than you do, or that the biggest obstacle to adoption has little to do with the product itself.

I wish I’d spent more time understanding these things before building so much software.

4. What Capabilities Must We Have?

Once you’ve decided where to compete and how to win, you need to determine what your company must be capable of doing to deliver on that strategy. Startups often approach capabilities in reverse. We assemble a team, look at what we’re good at, and build a business around those strengths. Sometimes that works. But it can leave you with a company that’s exceptionally good at things customers don’t particularly value.

Suppose your strategy depends on providing a dramatically better customer experience than an established competitor. You might need excellent customer research, unusually responsive support, an architecture that allows rapid customization, and salespeople who understand the customer’s business deeply. Hiring more talented engineers won’t necessarily solve those problems, even if engineering is where the founders feel most comfortable.

This requires deliberate choices about hiring, organizational design, and resource allocation. The easy answer is to keep blindly investing in R&D. But every dollar spent building one capability is a dollar you can’t spend elsewhere. When competing against companies with far greater resources, you need to choose carefully where you’ll become exceptionally good.

5. What Management Systems Are Required?

The fifth question concerns how you run the company. What should you measure? How should decisions get made? What behaviors should you reward? And how do you ensure the organization operates in ways that support your strategy?

Management systems can easily undermine an otherwise reasonable strategy. A company might decide to win through exceptional customer service while compensating salespeople on customer acquisition and measuring support teams by how quickly they close tickets. Everyone can meet their goals while collectively making the strategy harder to execute.

Metrics are particularly easy to confuse with strategy. Revenue, pipeline, engineering velocity, and customer acquisition all have their place, but they should help you evaluate your strategic choices. If your advantage depends on faster implementation, measure implementation speed. If you’re targeting a specific customer segment, understand whether you’re winning those customers and why.

Your management systems should help you recognize when assumptions are wrong and determine whether to adjust course. Distinguishing a strategy that needs more time from one that’s fundamentally flawed is difficult, especially when people have invested years pursuing it.

The Lesson I Wish I’d Learned Earlier

Silicon Valley had good reasons to reject traditional business planning. Elaborate five-year forecasts were rarely credible, and founders could spend months preparing documents that became irrelevant after their first serious customer conversations. I still believe building products, getting them into customers’ hands, and learning quickly are essential to starting a company.

The mistake was allowing that skepticism to extend to strategy itself. We became comfortable improvising, experimenting, and moving quickly without asking whether what we learned should fundamentally change where we competed or how we intended to win.

Looking back at my startups, I wonder how many decisions would have been different if we’d worked through these five questions more rigorously. Would we have chosen narrower markets? Invested in different capabilities? Recognized competitive threats earlier? Spent less time building features and more time understanding how customers made purchasing decisions? I can’t know the answers, and I’m wary of rewriting history to make every failure seem avoidable. Building startups is difficult, and even a well-developed strategy can fail. Markets change, competitors respond, and reasonable assumptions turn out to be wrong.

But I think we could have made better decisions. We could have been more deliberate about which assumptions to test and more disciplined about revisiting them as we learned.

Playing to Win gave me a practical way to do that. Its five questions help you make choices, test whether they fit together, and identify what you need to learn before committing more resources.

I still think talking to customers is one of the fastest ways to learn about a business. After two decades, though, I’ve developed a much greater appreciation for knowing which questions you’re trying to answer before you start talking.