Be Running Up That Hill
How Basecamp’s Hill Chart provides a useful frame of reference to master the Startup chaos
Working at startups can often feel as an exercise in balance. With so many things happening at the same time, and with multiple forces pushing to different and often opposing directions, one can easily feel quite disoriented. This digital vertigo is further exacerbated by the fact that any member of the team usually wears more than one hat, and so juggling becomes the de-facto national sport.
All these conditions often translate into a mentality of ‘let’s just do it’, which might seem as the only modus operandi available given that traditional processes just don’t work at this environment. This can be attributed to at least three characteristic apparent in a startup settings:
- Startups are risky — by definition, it is an environment of extreme uncertainties, fighting against an alarming statistics that >90% of the things you will try are likely to fail.
- Startups are chaotic — building a structure into the culture is often perceived as a way to kill innovation and curtail agility.
- Startups are opportunistic — the risk of forgoing a quick win or a way to get traction is very high, and it’s hard to balance long-term strategy with short-term gains, often giving the latter the default priority.
With so much at stake, it is not surprising then, that luck rather than process tends to creep into our overall thinking of what will make a startup successful. But this is a tendency we must fight rather than embrace. Relying on luck in an environment where the odds are inherently against us, is not unlike surrendering to a high-fat diet when you suffer overweight; and is in fact, giving the upper hand to what is most likely to end up killing you.
With so much at stake, it is not surprising then, that luck rather than process tends to creep into our overall thinking of what will make a startup successful. But this is a tendency we must fight rather than embrace.
Obviously, these observations are hardly new and have been written about and discussed extensively in innovation management literature, such as Steve Blanks’ Customer Development, Eric Ries’ The Lean Startup, Clay Christensen’ ‘Competing Agains Luck’ and more. These books, and others, are tackling the exact idea of how luck is the enemy of process and what a startup innovation should look like in order to increase its chances to meet a product-market fit. There are many good ideas in these books, but they don’t necessarily provide very practical tools for entrepreneurs to make decision on a day-to-day basis; this is where The Hill Chart comes into play.
The Hill Chart
The Hill Chart is a concept that was brought to life by Basecamp (formally ’37 signals’) who are known to innovate on many agile areas of project management execution, such as the modern ‘to-do-lists’. They are also the brain behind the highly recommended book — “Getting Real”.
The Hill Chart depicts in a visual way the lifecycle of a product idea, based on what is our level of understanding of it.
It looks like this:
Being a hill, it has both an upward slope and a downward one. Roughly speaking, these separate slopes represent the two distinct modes by which features or ideas are introduced into the software manufacturing process. The left (upward) side represents discovery and focuses on the phase of the project (or idea) when uncertainty is high. The key objective of this phase is learning. The right (downward) side represents delivery and focuses on the phase where product requirements are generally defined and clear and the level of certainty with respect to the market need is high. The key objective of this phase is working software.
The Hill Chart is both very simple and highly useful in that it allows an organization to get a quick idea of how projects and roadmap items are positioned with respect to their level of certainty. It also nicely depicts to what extent the company is balanced between doing innovation (left) and executing (right).
Let’s consider few additional aspects related to the Hill Chart:
Things Look Different At Each Side Of The Hill
It’s important to realize that each side of the hill represent a very different approach, and calls for a different mindset and methodologies. Much of the innovation literature, from lean to customer delivery to design thinking focuses on how to ‘figure things out’. Generally speaking, the key critical functions of the upward slope are Product Management and Product Design, that are tasked respectively with optimizing for the business and for the user experience. The downward slope is the territory of Engineering and is optimized on providing working software on-time, on-quality and most importantly, one that delivers on the product and UX desired outcomes.
Many companies, at their early stage, tend to mix these two separate modes into a single process, or more often than not, kind of leapfrogging the discovery mode altogether. Velocity in physics means both speed and direction; so focusing on the downward slope only could mean moving at high speed to the wrong direction.
Both Slopes Deserve a Process
At 2001, 17 software developers met at a resort in Utah, and few days later, brought down from the mountain what was to become The Agile Manifesto. That manifesto has articulated a set of values and priorities for software developments, which were:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Since then, Agile has become the de-facto development philosophy for most companies, boosting popularity to methodologies such as Scrum, Kanban, SAFe and XP. Unfortunately, none of these cater for the part of the process that deals with figuring out what to build in the first place. The hill, through the Agile lens, starts at the top, with no ascending. Agile teams expect to be told what to develop, and giving no regards to the slope that leads to that starting point. In other words, they don’t admit discovery in.
Since the incarnation of Agile, they were some efforts made to embrace discovery in, both by UX masters like Jeff Gothelf (Lean UX) who advocates for product design inclusion in the Agile process, as well from the Agile gurus themselves, but largely speaking, these efforts recognize at best that product and UX should be considered as citizens in the Agileland, often merely as second-class one.
Agile deals with producing software in small batches and at high velocity. It’s a better approach for sure, but without a sound discovery process, we would still end up producing the same amount of waste.
Instead, discovery deserves its own process and cannot be left as a “UX whim”. A startup, with its >90% failure rate, is bound to produce a lot of waste — all those features we end up scrapping due to market disinterest. Lean and UX deal with reducing that waste; Agile deals with producing software in small batches and at high velocity. Without the left side of the hill, all we will be doing is throwing out waste in many small buckets, rather than in one big garbage bin. It’s a better approach for sure, but without a sound discovery process, we would still end up producing the same amount of waste.
There Are Little Hills Along the Hill
Hill Charts can be created in many resolutions. There is the company-wide hill showing the big projects and initiatives, small hills for each product, and even smaller hills for single features. Almost everything we do goes through the same process of first figuring it out, and then executing it.
So rather than thinking of our landscape as a one giant hill, we should instead picture it as having small hills spread out along the slopes, and even smaller ones staged on those.
For example, a company may have a mature product which is already well-situated on the right-end of the company’s hill. This may be the classic “cash cow” of a company. That doesn’t mean that no innovation funnels to the product plan, and similarly doesn’t mean that we have ‘figured everything out’. We all know how quickly market and technology trends emerge or die, and it is critically important for a mature product to continue embrace new ideas, both to keep it relevant to existing customers as well to open up to new segments and markets. In such a case, we can envision a hill (the product) placed at the right-end of the company hill, with a pinpoint placed on its left-end side, to represent the new feature.
Conversely, that same company may decide to reach out to a new market or industry or just solve a new problem to its existing market. In all these cases, they will be entering an uncharted territory which calls for a customer discovery process and an articulation of a business case. This project, will be placed at the left-end of the company hill, far from its mature product relative. But in both cases, there should be a discovery.
Running Back to the Starting Point
The Hill Chart is misleading in one aspect; it may give the impression that we march out of the other side of the hill as victors of our game. We should recall however that the entire lean cycle talks about the Build-Measure-Learn loop. That means that very often our development process is the basis for new uncertainties, which in turn sends us back running to the beginning of the hill for a new cycle.
The Hill Chart may give the impression that we march out of the other side of the hill as victors of our game. But very often our development process sends us back running to the beginning of the hill for a new cycle.
This of course can happen at all the resolutions discussed above, and one thing to be minded to is the cadence of the company with respect to hill climbing. A truly agile organization is one that has troops scattered ,rather uniformly, at all times, across different areas of its hills, with a lot of running and moving around. One way to measure that cadence is by taking periodical snapshots of this terrain and observing the mobility it shows.
Hand-offs and Dual Tracks
The last topic worth discussing is how projects and tasks are handed-off between the left-side and right-side of the hill. I dare to say, that this is by far the highest friction point of product execution and so something that should be addressed with extra consideration.
In many ways, the hand-off is driven by the organizational structure of the company. The traditional structure, which is still the prominent one, is that companies are organized by functions, so you have a product management team, a UX team (which may, or may not, be reporting to the same head as product) and an engineering team. That structure pretty much entails that product and UX will spend most of their time on the left-side, while engineering on the right-side (as a side note, faithful to the Scrum torah, I consider the Product Owner as part of the engineering team, and separate from the Product/UX).
In such a scenario, communication becomes critical as many things tend to fall between the cracks or get misinterpreted at the hand-off at top of the hill. Regular meetings, ceremonies and a slew of product and UX artifacts are the norm to ensure improving the hand-off process.
There is a better way, however, which is having no hand-offs at all. This is harder to build but can have a much better outcome. The idea is to have a single squad team going through the entire hill. That doesn’t mean that everyone is doing everything. Product designers are unlikely to code more than developers will do customers interviews, but it does mean that the team, as a whole, shares a unified sense of ownership and accountability to the full process. Beyond the clear merit of a much smaller chance for dropouts, it provides a lot of opportunities for engineers to take part, as witnesses and even as contributors, in the customer discovery phase, which allows them to develop empathy that would later help in a better outcome of the software they build.
Product designers are unlikely to code more than developers will do customers interviews, but a squad structure does mean that the team, as a whole, shares a unified sense of ownership and accountability to the full process.
More and more companies are moving to squads, and UX gurus such as Jared M. Spool and Jeff Patton are strong advocates to this approach. Pattons’ dual-track development is a great starting point to get a grasp of how this works.
Building predictability in the unpredictable nature of startups is a hard task, but it’s the most effective way to fight against the goddess of pure luck. Investing only on the predictability of working software (read: Agile) is not enough and does very little to reduce waste or keep us in the right direction.
The Hill Chart is a simple and effective way to gain a good understanding of our investment both in learning and in delivery to make sure that they are effectively balanced.