Kill the Product Backlog

Sometimes nothing can be a real cool hand - Paul Newman in Cool Hand Luke

Like many startups, at Sefaira we are organized with the goal of reducing the lead-time from feature conception to feature delivery. This forces us to constantly evaluate our product development process & tools, with a clear goal in mind. Amongst many virtues that underpin this goal (measured as time to production), is the idea that shorter lead-time allows the product team to be more reactive and nimble (yes, Agile) to customer needs.

Typically (i.e. not in product discovery mode), product managers understand customer needs, create user stories & use cases, discuss them with the development team to help the team understand the problem, followed by estimation and scoping discussions. Following this, the features are broken in multiple customer facing releases. Good product managers identify data they’d look for before building features, i.e. good old hypotheses driven iterations. New features are often balanced with improvements, bug fixes as well as technical improvements, and prioritized by the product manager.

To manage all this seeming chaos, &  queue up work, some product teams lean on creating and maintaining backlogs. This is a great idea – the product manager logs & maintains all disparate items, sorts and sifts through the backlog working closely with other stakeholders, and lines up work for the development team, and good development teams crank out code and deliver features. If the business wants to know what’s coming up, the product manager leans on the backlog, which is supposed to be a reflection of the product outlook 2-3 months out. This is comforting, sturdy and has the signs of a well-oiled machine. So where’s the problem?

There are 3 key problems here.

Backlogs substitute judgment

Good product managers are always on the lookout for new information to influence product direction. This is intended to influence features to build, bugs to fix, areas to invest in, etc. As new information appears, the product manager with a well-organized backlog goes ahead and prioritizes work in the backlog based on this information. This is where the problem starts. 

The backlog was created when the said new information wasn’t available. While this seems reasonable, what is really happening is that the product manager is using new information to confirm existing work queue. This makes an agile team less reactive to customer needs! What should have happened is that the new information, in concert with P+L goals of product & product vision be used to create new work – as often as necessary. This is discomforting, difficult and keeps me up at night. And if I am uncomfortable, I know that I am exercising judgment. I work with stakeholders to queue up work every sprint based on product outlook (more on this below) and latest information.

Backlogs are cognitive black holes

Once a backlog exists, maintaining it, defending it and justifying it takes up significant cognitive effort. It also becomes a basis for defending product decisions. One of the frequent responses to new requests is “It’s in the backlog”, and this is interpreted as “We got it”. Backlog gradually ends up becoming one of the measures of competence and organization of a product team. It is not hard to see why this is an easy trap to fall into. Backlogs also sap significant cognitive resources – resources that could be brought to bear in gathering & organizing new information with intent to act in immediate future.

Backlogs are poor predictors of product outlook

When asked what we are going to build for our customers in the next 2-3 months, backlogs seem to be the natural place to go look for answers. After all, backlogs are a manifestation of product roadmap and priorities. But if you think deeper about it, product outlook should be based on most recent information that the product team has. Product backlogs by definition are historic. Therein lies the dissonance between product outlook & product backlog. I think product managers should update and maintain product outlook very actively (once every 2 weeks), and update all stakeholders regularly.

Now that I have made the case for killing the backlog, there is a natural question that arises. How do I make sure nothing falls through the cracks? The answer here is simple – stuff will fall through the cracks, and that’s okay! Any fast moving development team (where code is in a good state & movable) can move quickly to pick up items that fall through cracks and deliver it quickly. Its better to have things falling through cracks and have someone notice, than overbuilding or building based on historic information ala the backlog.

Till then, I leave you with this great scene from one of my favorite films “Cool Hand Luke”.

It takes three to tango

In the age of SaaS, lean and a world where rate of improvement of technology is outpacing the rate at which development processes can catch up, understanding roles of various stakeholders in a software development organization becomes more critical than it has ever been.

For building a successful product, there are three key stakeholders who need to work closely together. These are the CEO, the head of product, and the head of software development. All three have unique perspectives, differing priorities, and different roles to play in order to make the product & business successful. This post was motivated by our mission at Sefaira, as well as posts by visionaries such as Ben Horowitz.

Head of development

• Asset quality - Code is a software company's top asset (some would say customers are, and I would agree but this is a chicken & egg scenario), and the product is an extension of the code. There are many other things that play a role in how a user experiences the product, but it turns strongly on the quality of code. I see high quality as a very important goal for head of development. This implies everything from right approach to testing, understanding requirements, ensuring collaboration between developers, etc. Further, I view asset quality & velocity as virtuous traits, and that there is no tension between these two.
• Deployability of assets - In line with the lean approach, especially relevant for start ups, is the ability to deploy code quickly. This implies that code should be movable & deployable at very short notice based on business needs. This requires very good architecture, which starts with accepting that business needs can change, and assets shouldn't become brittle. This ranges from architecture itself, and includes technology choices, language choices as well as infrastructure choices.
• Lead time to creation of assets - How quickly a team goes from raw materials to shipped product is a key KPI for a development team. Assets by definition need to be shipped, otherwise its just inventory which is a liability for software teams. (We have all heard of feature-branch management, and how this can sap valuable time).

Head of product

• P+L of product - Head of product needs to absolutely make sure that all decisions are weighed by cost-benefit analysis (first & life cycle), and benefit is defined by core metrics, which can vary from company to company (market share vs. revenue or some mix of the two). For SaaS companies, engagement is vital & can be defined by new customers using & paying for the product, as well as existing customers increasing time spent using the product continues. This is a key leading indicator.
• Realizing the product vision - Coming up with strategies such that the product roadmap is always in sync with the product vision, and enacting product vision while maintaining a watchful eye on P+L of the product is key. This becomes very critical if there is tension between what sales teams might need, vs. the product vision. Breaking this down further, the head of product needs to keep an eye on day to day execution in terms of requirements of product being translated into assets, constantly ensuring that the product doesn't creep away from original intent.
• Business needs vs. state of assets - It is vital to ensure that assets are being created, & moved to fulfill business needs, and this is the responsibility of head of product. Further providing visibility to the business on the state of assets, and the direction being taken with assets (in terms of how this is the right thing for business needs). In order to do this, head of product is constantly investing in small bets, always course correcting to minimize the gap between what the business needs, and what assets exist & their deployability.

The CEO

• Standard bearer for product vision - The CEO is the standard bearer for product vision for most start ups. The CEO maintains and encourages the drive towards realizing product vision. She enables the head of product to drive towards execution of vision, always ensuring that there is a viable strategy of reconciling short term business needs with long term vision.
• Voice of the business - Before you cry out loud about how the head of product is the voice of business, read on. With goals of heads of product & development stated above, the CEO needs to spell out what the business needs from product to enable day to day execution. The CEO understands (and should understand) the customer journey end to end, and will know what various functions need from the product to execute successfully. A simple example of this is integration of customer engagement platforms such as Totango with the product, to drive customer segmentation & success.
• Magic - I don't know what to call this, or how to quantify this in terms of core metrics but this is pure CEO craftsmanship ranging from aspects of customer experience to good citizenship. I welcome examples of this. Absent of better classification, we'll just call them "nobody's problems but the CEO's"

I wonder how other start ups organize around these stakeholders as they pursue their mission.