X
    Categories Performance Monitoring

Product Management: We Need Pipelines, not Roads

Living in Vancouver, surrounded by the natural beauty of British Columbia, it’s hard not to elicit a negative reaction (if not an outright protest march) when talking about a “pipeline”.

But you’ll bear with me, right?

AppNeta is a growing company with bright employees and savvy customers. But, like any company on the rise we’ve endured our share of growing pains. To address this we’ve embarked on a campaign of organizational change over the past year, and in this post I’ll share one of our success stories.

I’ll start with motivations for focusing on something close to my heart: product planning and development. From there I’ll describe the guiding principles for our transformation, and finish with a summary of our solution: the product pipeline. In follow-up articles I’ll detail specific use cases to demonstrate how our product pipeline helps us deliver value to our customers.

The “good old days”

The tools, practices, and processes that work when a company is ten people hardly scale when you grow to one hundred people, let alone beyond that.

Anyone who has experienced life in a rapidly growing organization can identify with these two common issues:

  • As teams grow, divide, and specialize, silos form and (of necessity) people focus on their area of influence.
  • The more established the silos, the fewer bridges exist between them.

For us at AppNeta, this resulted in separate meetings with people discussing the same things – but usually not with each other. At times there were misaligned priorities and expectations, and some great ideas went unrealized as only a few felt empowered to be proponents of change.

Each team was using their own system to manage tasks and share information, and there was little collaboration between our engineering team members and the rest of the organization.

While these issues are commonplace, we knew we could reduce friction in our product planning and development lifecycle by addressing them. During a gathering of the product and engineering leadership teams we vowed to do just that.

Start with principles (not processes, practices, or tools)…

From the outset, we identified the following principles to guide the evolution of our product planning and development lifecycle:

  • There must be one source of truth, so everyone can update and refer to the same information regarding our product roadmap, work in progress, and completed initiatives.
  • Dates, commitments, requirements, and scope must be transparent, so everyone has an accurate view of product engineering at all times.
  • Everyone must have the ability to add to the list, so great ideas from all sources are up for consideration.
  • Everyone must have a voice in prioritization, so feedback from any source can positively influence product engineering efforts.
  • Priorities must be unambiguous, so it is clear to everyone what we are working on, and what is next.
  • We must be able to collaborate across the entire organization, so we can collectively provide more value to our customers.
  • We must plan for more than new features, so we make time for activities vital to our growth and success, such as technical-debt reduction.

Anyone familiar with the Twelve Principles of Agile Software (from the Agile Manifesto) will see where much of our inspiration originated.

… and finish with a Pipeline!

We set to discussing how these principles could be combined to form a simple process (with supporting tools) which could be used by the entire organization.

We conceptualized our product planning and development lifecycle as a pipeline, with items moving through the following stages:

  Inbox   : This is where features / enhancements / ideas for the product are born.  Anyone at AppNeta can propose, comment on, and support these items.  The Inbox is an open discussion forum that is watched closely by the product  team.

  Backlog   : Items are promoted to the Backlog by our product team to reflect our intent to build that item at some stage. The Backlog is kept as a prioritized, ordered list. The product team focuses attention on gathering requirements and feedback for items near top of stack.

  Review   : When details of a change have been well defined, the item is moved into Review by the product team. This is the trigger for engineering to plan for delivery of the item in an upcoming release. As with the Backlog this is an ordered list, with more effort spent on items near the top.

  Commit   : Once we have a plan and people available to work on it, an item is moved into Commit by the engineering team. The discussion regarding requirements, and collaboration with the rest of the organization continues.

  Done   : Once an item is released, it is moved here for posterity. We can always refer back to what was implemented, and why. Any requirements which weren’t satisfied return to the Backlog for future consideration.

Wait, isn’t that just a product roadmap?

No. It’s much more than that.

Traditional product roadmaps are usually updated by a select few and visible only to the ‘decision-makers’. They are updated manually and can easily become out of sync with reality at the best of times, and at worst are ‘aspirational’ rather than a true representation of ability to execute.  Being a high-level summary they are selective in the information they convey, with few ties to detailed information or work not in scope during the next few months or quarters.

On the other hand, our product pipeline is open and transparent to everyone in our organization. It is kept up to date in real time, and is an accurate reflection of our ability to execute. It is an account of all significant engineering work* – completed, in progress, and future – from initial motivation to delivery. While detailed, it can be filtered to show only the high-level details conveyed in a traditional product roadmap.

* The caveat being general defect tracking, which we handle using our triage process.

See Mike Hustler’s informative The Most Agile Way to Manage Technical Debt for details.

So, what’s next?

For the sake of brevity I’ve avoided mention of the fantastic tool we use to support organization-wide input to our product pipeline – Asana. If you haven’t used Asana before I highly recommend you take a look.

In follow-up articles I’ll illustrate how we utilize Asana for each stage of the product pipeline, and detail specific use-cases of how we collaborate using this amazing tool.

Stay tuned.

Nick Austin: