The Startup Patterns Strategy Stack

"We've just had a big new opportunity arrive in our lap. We're going to need you to drop what you're doing and put all your attention on it."

I remember hearing this a lot as a new technology leader. One CEO in particular seemed to come to every weekly meeting with a new direction for our fledgling startup. They chased one shiny new idea after another, lacking any specific focus and direction. And it was we in the product development group who had to actually do the running around.

The result was a harried and overworked team, running back and forth trying to satisfy the leadership's latest "big idea." Over time, key staff burned out and left the organization. And with every departure, the company was left with a higher concentration of those people who weren't comfortable pushing back on leadership's whim, further exacerbating the problem. Eventually, the company failed entirely.

Nowadays, when clients describe this sort of situation, my go-to assumption is that the company lacks a clear strategy. There is no clear strategic model against which to gauge any particular new opportunity as worth chasing or not. I've been helping leaders develop their strategy for a while now, and over the years I've learned to break the overall company strategy into a three-layered stack of interlocking sub-strategies.

The Stack

There are three layers of the Startup Patterns strategy stack, each of them dependent on the one above to give it critical inputs: the business strategy on the top, the product strategy supporting it, and the technical strategy supporting them both.

The CEO is responsible for the business strategy. Other officers and staff can certainly contribute, but it's ultimately the CEO's burden to bear. Similarly, a Chief Product Officer (or whoever the highest level product person is) should bear the responsibility for managing the product strategy. Finally, the CTO (or equivalent) must own the technology strategy.

All three strategy layers must fit together neatly, or there will be problems. So it's vital these three leaders collaborate closely in the formation of each layer in the stack. If one layer changes, it will affect the other two.

The Business Strategy

A successful business makes money by delivering value to a customer in a repeatable and scalable fashion. The business strategy is intended to focus the company on achieving specific business outcomes, given the resources available and the constraints in which it operates. Therefore any decent strategy must include an accounting of resources and constraints, as well as specific measurable goals.

A strategy need not be overly complicated. The more complicated it is, the more it is likely to fail. If you cannot explain your strategy to your newest employee in just a few minutes, it is too complicated to be successful. A good strategy needs to be simple and elegant.

The main components of your strategy are your goals (just a few), a list of your resources, a list of your constraints, and a set of concrete milestones against which to measure your strategy over a specific time. Resources should have real numbers associated with them (dollars, people, units, etc.). Without these concrete amounts, your strategy will just be a fantasy.

Next, you must model how you will apply each of your resources to reach each milestone in the appropriate time. Your resources are finite in real life, so any strategy that doesn't take that into account will be wishful thinking. Once you've applied some resource to a specific part of your strategy, you can't use that portion of resource again. You don't need fancy tools for any of this. A spreadsheet should be sufficient.

Lastly, you'll want to compose a few risk scenarios, say, for losing resources unexpectedly or facing a constraint sooner than expected to see what happens. It is a good idea to construct a few different scenarios in order to simulate different possible outcomes (the arrival of a new competitor, losing your biggest customer, losing a key employee, etc.) and pick the most resilient strategy from those simulations.

Once you have modeled a few different scenarios, your best path forward should be coming into focus.

The product strategy

The product strategy follows from the business strategy. Indeed it takes the business milestones as its goals. It's also composed of resources, constraints, and milestones. But they are translated into a product development context.

For example, in the business strategy, we may have identified people like software engineers, product managers, and designers as a key resource. We will have modeled how many people we need, of course, and how much we are paying them. The product strategy will then also refer to this resource, but this time, it may be configured into cross-functional product teams, with each team executing a specific aspect of the product strategy.

Note: Building a strategy is probably the only time it is OK to refer to people as "resources." Outside of this activity, it should probably be banned from your vocabulary.

Constraints will also appear in the product strategy. Sales lead times, marketing costs, competition in the market, and technical limitations are all constraints that products are bounded by. The product strategy should account for these.

Note: Here in the middle of the stack, you can start to see how the three layers interact. Product strategies must pull milestones from the business strategy as goals, but they are also constrained by the tech strategy's constraints. The three layers of the stack must be developed together and validated against each other.

The product strategy's resources and constraints are modeled to achieve the goals by hitting specific product milestones. Those product milestones are then passed down to the technology strategy as its goals.

As with the business strategy, risk scenarios should be modeled here too. What if we're wrong about this particular aspect of our product? What if we're late shipping by a month due to some unanticipated tech constraint? Model enough different risk scenarios to be relatively confident in your approach.

The tech strategy

With the business strategy informing the product strategy, it is time to lay out a technology strategy to support both. The milestones of the product strategy become the tech strategy goals. The resources from the product strategy can be converted into resources that technology teams care about.

Similarly, the constraints, particularly technical ones, are further fleshed out in technical detail. Finally, tech milestones can be developed to support the product milestones above, and the business milestones above that.

A technology strategy should articulate the specific people, tools, programming languages, platforms, data, and services that will be used as resources to achieve technology goals. Similarly, the constraints of those people, tools, programming languages, platforms, data, and services can be modeled to account for risks in the technology strategy.

As in the two layers above, it is always a good idea to model risks such as running out of a critical resource (what if our best front-end developer quits?) and encountering constraints earlier than we expect (what if AWS raises their prices unexpectedly?).

Evaluate Your Strategy Stack

Now, we have all three layers of the Strategy Stack drafted. We have collaborated closely so that all three layers fit neatly together, and there is little ambiguity about how to respond to any specific depletions of resources or sudden arrival of new constraints.

Like everything else, you'll want to treat the strategy like a product, and iterate and improve it over time using feedback from the real world. The three corresponding owners of each layer of the stack (CEO, CPO, and CTO) should meet regularly to compare their goals and any progress that has been made.

Over time, as you execute against your strategy stack, you will see whether or not changes need to be made based on whether you actually reach your milestones within the appropriate resource levels.

Don't be afraid to change the strategy based on new data. As data comes in related to progress (or not) toward a milestone, the corresponding strategies in the rest of the stack should be updated to reflect it. Changes to any one layer of the stack should not be made without close collaboration with owners of the other two layers.

Get Help With Your Strategy Stack

We've been through this many times before with many companies. Need help getting your strategy straightened out? Get in touch, and we'll give you a hand.

Also, we're working on a template for the Startup Patterns Strategy Stack that you can use to build your own version. Post a comment below if you're interested in trying it out with us and we'll reach out to get it to you.