The Keys align us
The Keys help keep teams focused and aligned on outcomes that matter to users.
Hills align us as teams
Hills are statements of intent written as meaningful user outcomes. They tell you where to go, not how to get there, empowering teams to explore breakthrough ideas without losing sight of the goal.
Get in sync
Here’s the truth: on complex projects, things don’t always go as planned. A never-ending stream of feature requests and technical roadblocks threaten to derail progress, delay releases, and throw even the healthiest teams out of alignment. Despite these uncertainties, how can a team stay true to a project’s intent?
Hills communicate our intent for a project with clarity and flexibility. They frame problems as intended user outcomes, not predetermined implementations, empowering teams to discover breakthrough solutions. They help us keep the eye on the prize, even in spite of the many challenges that stand in our way.
Anatomy of a Hill
To write a Hill, start with the user you want to serve. Next, specify the outcome you want to enable them to achieve, and the differentiator that will make your solution worth their while. We refer to these elements as the Who, the What, and the Wow.
A good Hill is implementation-agnostic. It should specify what users are trying to accomplish, not a tool they’ll use to do it. If you read your Hill back and it feels like it already describes a specific implementation, take a step back and try again.
Who
Who are your users? Make it clear who you aim to serve—and who you don’t.
What
What’s the need they’re trying to meet? Turn user needs into project goals.
Wow
How will you differentiate from competitors? How will you measure success?
Examples
A GMU-based sales leader can assemble an agile response team in under 24 hours without management involvement.IBM Connections, 2012
It should take no more than 30 minutes for a developer to build and run an app using IBM and 3rd party APIs.IBM Bluemix, 2014
I believe that this nation should commit itself to achieving the goal [...] of landing a man on the Moon and returning him safely to Earth.John F. Kennedy, 1961
Managing with Hills
If you’re on a product team, Hills are owned by Product Management and defined in collaboration with Design and Engineering. If you’re on a service team, Hills are owned by the senior client stakeholder but defined in collaboration with the delivery team. Work with your client to arrive at well-defined Hills your team can feasibly achieve within your constraints.
Don’t worry about writing perfect Hills on Day One. Hills should evolve based on your understanding of the problem. As you iterate, hold Hills Playbacks early and often. Your Hills can change right up to Playback Zero—that’s when you need to really commit.
Three Hills, one Foundation
You can do anything, but you can’t do everything. Hills should reflect an investment in the most valuable outcomes for your users, and the most important differentiators for your organization. That’s why we strongly recommend that a project takes on no more than three Hills at any time. This helps you maintain a focus on a manageable set of goals.
In addition to the three Hills, invest a portion of your resources to the Foundation to either fix issues from past releases or put a down payment on groundwork for your project’s future.
Commit resources
Allocate resources to your Hills and Foundation based on their relative value to your users and your organization. Form Diverse Empowered Teams around each Hill and equip each one with the expertise and authority needed to deliver their outcome independently. Strive to recruit at least one Sponsor User per Hill.
Once resources have allocated to a Hill, treat them as thread-safe investments. Hills provide the language to have outcome-driven conversations around your resources. If a Hill needs additional resources, base your decision to reallocate on the value of each investment.
For example: let’s say you’ve allocated 25% of your resources to each of the three Hills, and the remaining 25% to the Foundation. If something in the Foundation goes wrong, ask yourself: is it worth the risk of diverting resources from a Hill to fix it?
Break them down
Sometimes a Hill is necessarily complex and might benefit from another level of decomposition to further divide the work. If you choose to write Sub-Hills, make sure each one is still a proper Hill that, if independently released, still delivers meaningful value to users.