The 3 Horizons: balancing risk, ego, and innovation in big organizations
By: Josh Dormont
Tags: Edtech, Innovation, Government, Lean Startup, Product Management

Lean, Governance, and Government weren’t designed to go together. Neither Lean’s origins in manufacturing where things were pretty standardized to the ideals of the Lean Startup that banks of rapid iteration mesh with the convoluted ecosystem of government.

But there’s a concept from the world of Lean Enterprise that can help re-shape and inform how new technology is developed (and old tech is improved). It offers promise for how to implement a governance framework in large organizations, but as we’ve learned, execution may be the easy part. Changing hearts and minds is an under-appreciated aspect of the work.

Three Horizons

The theory behind the Three Horizons stems from an early paper by a few McKinsey partners in the Alchemy of Growth that describes three different trajectories for businesses and technology. Briefly, the three trajectories are:

Horizon 1: Existing, well understood products that need continued optimization and excellence in execution. In education, these are our primary Student Information System (SIS) and our roster/personnel systems. They’re core, well-understand product domains. Horizon 2: Next generation products whose needs are understood and a solution is evolving but may not have reached scale. Put in Lean terms, you’ve found product-market fit and are pushing to a new channel or transforming a key part of the business model or even adding new features to capture new value (solve new user problems). In education, many content and assessment solutions are in this category, evolving with increasing personalized features and insights. Horizon 3: Emerging products that deal with many unknowns. This is the area that enterprises and government bureaucracies tend to get wrong most often because they treat products in this horizon the same way they treat Horizon 1 and 2 products. Steve Blank has a brilliant and funny talk on just this subject. In education, we’re seeing the rise of machine learning across content, assessment, and intervention/support.

So how does an understanding of the three horizons lead to a shift in product management and governance within government?

Make the Horizons Actionable

First, categorize your products into each horizon. This creates and allows for psychological safety for the teams that are most attached to the legacy and core systems. Their work and knowledge is critical to the success of the whole system and while down the road maybe there will be some shifts, recognizing these systems for their importance to critical business processes establishes trust. The people working on these products aren’t less innovative or creative than others, but are likely there by circumstance.

Second, leadership should establish clear goals for each product team and a staffing model for each horizon. Horizons 1 and 2 might be best staffed by teams who are content experts and can manage their work largely autonomously. Teams should not be spending the bulk of their time squeezing out incremental gains for the products in Horizon 1. However, Horizon 3 work might offer opportunities for teams to practice new skills and develop new relationships in a lower-stakes setting.

Third, create a system for identifying new problems to solve. These problems should come from a blend of what leadership has identified are key org priorities, established user needs from user research and help-desks, and the ideas of people across the organization. There are many different ways to do this and in a later post I’ll share some of the practices I like best and lessons learned along the way, but what’s important is that the processes are inclusive, evidence based, transparent, and linked to well defined org goals and priorities.

Fourth, establish a method for prioritizing those problems and holding the product teams accountable for what they’re learning and the value they’re creating. Each of these four steps are important, but this last piece is where I’ve seen tension build in corrosive ways. Get this wrong and product teams can feel like they’re mere puppets of leadership. Get it right, and you can rally people from across the org on projects that have enormous potential while building new skills and connections across the org. Let’s get into the details on this.

How to align the team around what to build/what to learn?

I’ve seen three different models for product decision making in government/non-profit that go from traditional IT models to more ‘rogue’ DIY (develop it yourself) approaches.

Each model has its own trade-offs and understanding them is essential to figuring out what is best for your current set up.

Rogue Development

In this model, teams hire their own developers, researchers, designers etc. to build applications that align to their own areas of expertise, focus, or goals. Despite the potential inefficiencies, this model frequently spreads virally and organically (e.g. Shadow IT). Once a team builds something that gets some attention, and then other teams will want to get in on the ‘product development’ work to have more ways of showcasing their greatness. These teams tend to run fairly nimbly and in some ways resemble little start-ups embedded within the organization. The trade-offs are:

Benefits: the more organic, bottom-up nature is good for exploratory and low-stakes projects that can stay under the radar.

Downsides: duplication of work, incoherent products for users, discrepancies in data, fragmented standards, and inability to scale. There are ways of addressing these which we’ll get to in a moment.

Business Team-IT Partnership

In this model, IT has business analysts who work with different teams to identify their needs for ‘technology’, puts them on a roadmap, and then builds it to spec using resources from IT. This is a pretty traditional set up, especially for organizations that aren’t primarily tech companies.

Benefits: this model allows for product expertise to be concentrated, standards developed, and more transparency into cost/value and resource allocation.

Downsides: this approach too often leads to solutions that are based more on business assumptions and fixed requirements than discovery and prototyping.

Steering Committee

Sometimes a Steering Committee brings together business and IT to better align on goals, priorities, and practices. Other times, a Steering Committee can be used to bring together multiple teams or groups that had been pursuing rogue development. Either way, it can be a blessing or a curse. It can help align priorities across business teams and product resources. But if those goals and priorities aren’t there, it can quickly become a space for other management issues to play out.

For many government organizations, this might be a useful way of bringing together leadership around a high-level ‘what’ that still gives product teams enough independence and autonomy to build, test, learn, and evolve. That combination is critical for ensuring good use of resources, but also for keeping talented product people who likely have options outside of government where they can make 1.5–3x their salaries.

Pick a model. Set goals. Create space to reflect.

Whatever model you pick or find yourself in, there are three elements that need to be in place:

Be explicit and transparent about the roles and responsibilities of decision makers. Whether it’s one individual (maybe a CTO) or a group (the Steering Committee), make clear what types of decisions they make and what others they help inform or consult on.

of decision makers. Whether it’s one individual (maybe a CTO) or a group (the Steering Committee), make clear what types of decisions they make and what others they help inform or consult on. Build in mechanisms for reflection and continuous improvement. If the group is coming together for the first time, this may actually be easier — they might be more open to vulnerable practices that recognize there’s no way they’re going to get everything right at first. Establish up front how the group will do this and where possible, lean on outsiders to help facilitate what can be difficult conversations. This work is a building block for developing trust both within the group and for creating credibility for those around it.

and continuous improvement. If the group is coming together for the first time, this may actually be easier — they might be more open to vulnerable practices that recognize there’s no way they’re going to get everything right at first. Establish up front how the group will do this and where possible, lean on outsiders to help facilitate what can be difficult conversations. This work is a building block for developing trust both within the group and for creating credibility for those around it. Establish values that prioritize the people doing the work. This might sound counter-intuitive and that’s why it’s so important. The group might have been convened to establish high level products goals and priorities, but arguably its most important responsibility is to create an environment that the product teams can thrive in. I’ll go into this much further in a later post, but as you’re setting up a leadership structure, you can check yourself on this by asking whether each process you’re putting in place is people centered. You need to be able to trust your teams and you need to be able to show that in how you do the work not just by saying it.

Thanks for taking the time to read this and I hope you have a little extra time to read more in this collection on product management in big bureaucracies and government (here, here, and here).

(Disclaimer: This piece does not represent the views or perspectives of the NYCDOE.)