What is business strategy? Michael Porter presented a succinct definition in his seminal article in the Harvard Business Review, first published in 1996: “The essence of strategy is choosing to perform activities differently than rivals do.”
Strategy is how a company wins against the competition. A well formulated strategy clearly communicates what it means for the company to win, states where the company should invest in solving problems for customers, and maps how they’ll solve these problems with solutions drawn from their competitive core.
Choosing to perform the right activities
The key words in Porter’s definition are “choosing” and “activities.” First and foremost, strategy is about choosing what to do and what not to do. In today’s world of compressed schedules and limited resources, making good choices can make the difference between owning the market and going out of business.
Second, vision without execution is just hallucination. Once the destination has been set, there must be a clear plan to take the company from here to there. There are many frameworks that help people marry vision with execution. My favorite is A.G. Lafley and Roger L. Martin’s Playing to Win framework, which is a great read for anyone interested in strategic planning.
“Hallucinating about the future”
Given the critical role strategy plays in helping a business succeed, how effective is strategic planning in an average technical organization?
As an engineering executive with copious experience contributing to business strategy development, I had a good chuckle at what Wally had to say in a 2014 Dilbert comic strip: “You basically hallucinate about the future, and then something different happens.”
All too often, a strategic planning exercise looks something like this:
Senior staff get together in a two-day, off-site workshop. We present the current status of our respective departments. We then lock ourselves in a room with lots of coffee and run an extended brainstorming session about where the company should go next.
We come out with a general direction and spend the next four months fleshing it out.
We present this plan to the Board of Directors, who review and approve it.
At this point one of two things may happen: We get swept away with what we were doing before the off-site and forget all about the strategy, or we plunge headfirst into a multi-year implementation plan, spend a lot of money, and don’t come up for air again until major deliverable X is ready for the market—and falls far short of expectations.
Wasting time versus slipping into a waterfall
In the first scenario, we have just wasted four months on a paper exercise. Perhaps the strategy would have worked—perhaps not. We’ll never find out, but at least it’s not actively harmful.
In the second scenario, we rashly made major investments without going out of the building and validating our hypotheses. This is actually much worse, because this is effectively the waterfall process.
The Waterfall Development Process. Image by Paul Hoadley. Originally uploaded to the English Wikipedia. Transferred from en.wikipedia to Commons. CC BY-SA 2.5 , via Wikimedia Commons.
Remember the bad old days when people spent months writing the market requirements document (MRD), product requirements document (PRD), and functional specifications before moving into design, implementation, verification, and maintenance? That stopped working years ago as a viable software development process. In this day and age, market conditions change on a daily basis. There is no way a two-year plan will remain relevant without frequent course adjustments.
In the same way that MRDs and PRDs can rapidly become obsolete, a multi-year strategy and execution plan can quickly become irrelevant in the time it takes to write them up and get them approved.
Borrowing a page from lean and agile
As we all know, there are two key problems with the waterfall process.
No customer feedback. All ideas are generated inside the building without continuous access to customer insights. The strategy is limited to the team’s understanding of the market and of customer needs, wants, and expectations. What if they are wrong?
Long feedback loop. To implement a two-year program plan is to commit to running open-loop on a giant investment without reality checks. By the time the company has something for the market to react to, the market will have moved and the deliverable may no longer make sense.
How can we avoid the trap of slipping into a waterfall process and ending up with an irrelevant strategy? There is another way: we can borrow principles from Lean Startup and agile methodologies to modernize strategic planning.
Lean Startup is built on several key tenets, including engaging in continuous customer development, avoiding waste, and building minimum viable products (MVPs) with which build-measure-learn experiments can be conducted with real customers in the field. The main thing that makes this work is rapid iterations. The rate of learning is accelerated by minimizing the total time spent running through the loop.
The build-measure-learn loop in Lean Startup. Image Credit: Ash Maurya, 2009.
Agile development also has a thing or two to teach strategic planners. At first blush, an agile process guru would balk at the idea of mixing “agile” with “planning.” The last line in the Agile Manifesto reads, “Responding to change over following a plan.” Taking a literal interpretation of the agile philosophy, one could assume that real agile practitioners don’t do planning.
Agile was designed by developers, for developers. It’s tuned to optimize the effectiveness of small teams. Strategic planning at the corporate level is fundamentally a big-team exercise involving business leaders, not developers. How can we take the essence of what makes agile development effective and apply it to strategic planning to make the process nimble and responsive to change?
If we stop being dogmatic about agile and start looking at its core benefits as a development methodology, it really comes down to one key takeaway. Agile fixes the two fatal flaws of the waterfall method: it provides a fast mechanism to incorporate customer feedback.
Let’s have a look at what’s going on with customer interactions in the context of an agile development cycle.
Agile development process. Image Credit: Henning (WMDE) (Own work) [CC BY-SA 4.0 ], via Wikimedia Commons
In agile, the product owner manages the backlog and ensures that insights from stakeholders are incorporated on an ongoing basis. The methodology creates frequent, testable deliverables at the end of each short sprint (typically one to two weeks). These deliverables can be used as stimuli in customer development interviews. This frequent customer interaction gives the product owner the raw data to create the right user stories and prioritize the backlog.
Let’s look at analogous roles, artifacts, and processes in strategic planning. The product owner is the strategist. The stakeholders include potential customers—not just end users of the product or service, and everyone else in the buying process: the economic buyer, the champion, the influencers, and those with veto power. They also include internal stakeholders, including senior management, the board of directors, and leaders of functional organizations.
The user story captures the fundamental needs of the stakeholders. The sprint is the process to develop a testable deliverable that hints at solutions that meet those needs (such as a product brochure). The standup meeting is a mechanism for cross-functional synchronization between leaders of different organizations (such as the head of marketing, head of engineering, and head of professional services).
Staying close to customer needs with strategic planning
In this light, we can see how strategic planning can take the long view and still stay tightly integrated with market and customer needs. Rather than spend months writing up a strategy and years implementing it, spend only days coming up with a first-pass strategy and only a couple weeks per sprint creating and testing components of the strategy in the field.
When we take this approach, we invariably invalidate many early assumptions in the first few sprints. This can feel terrible. But it’s far more wasteful if we don’t invalidate these foundational assumptions early on.
If we embrace the results we get back from this customer research and pivot as needed, in a few weeks we’ll start to find our way toward a strategy that works. At that point, we can start going into implementation, keeping the same spirit of quick iterations and frequent testing with customers to make sure there’s a strong mechanism to respond to changes over the duration of the implementation period.
Strategy gets a bad reputation because it’s often crafted by people who have no access to customers. If we inject the discipline of Lean Startup and agile development and make time for integrating customer insights into the process, it will dramatically improve the probability of success. Give it a try—you might find that you end up saving your company a lot of money.