Traditionally, development teams build products in horizontal silos of company hierarchy. For example, separate teams might deliver the front-end while another works on the back-end. The user experience might be defined months before development begins. The waterfall approach doesn't allow us to ship user value until several teams have delivered.

Product teams work vertically, meaning that we build the product one small feature at a time, with all the different layers being addressed in a single story. This allows us to frequently deliver new value to users because the entire team is in sync and aligned to one story. We're able to get rapid user feedback which helps us make minor adjustments sooner which de-risks the product over time.

One vertical user story may encompass GUI, client and backend work -- whatever is needed to deliver one unit of value.

As Product Manager, you'll work closely with your team to split development work into small, valuable user stories.

The smaller we can make a story, the simpler it will be to understand, estimate, implement and test. This also allows us to better predict when features will be ready to release.

Smaller stories mean developers can rotate through the codebase faster and switch pairs more often, increasing the overall knowledge of the product across the team. Making frequent, tangible progress as a result of smaller stories is good for business stakeholders, the users, and the overall team morale.

Product teams should practice continuous prioritization. While we do plan our work a few weeks at a high level, we don't commit to a sprint with a fixed scope. At any time we may learn about unexpected changes or new information from user testing or stakeholder interviews that challenge our current priorities. Continuous prioritization helps us maximize our responsiveness to changing conditions and navigate complexity and uncertainty better than if we were beholden to a rigid plan.

Priority is set by choosing the story order in the backlog. The Product team always works from the top story, so the order is important. It's the Product Manager's job to ensure that the order of the backlog represents the latest priority.

Product teams must frequently make tradeoffs between value, quality and constraints to successfully respond to change.

Making tradeoffs against the right goals

Project management and product management are two commonly applied mindsets when it comes to defining software success.

Project management is a tactical role responsible for delivering pre-defined requirements by a set end-date with a fixed budget. If the scope of requirements are delivered on the agreed-upon time and budget, the project is considered successful.

In the context of product development, project management solves for the wrong set of problems. A product's failure is rarely a result of being behind schedule or over budget. Failure is building products customers don't want or need. Successful products must also create sufficient business value.

Products require a different, more strategic role: the Product Manager. Product Managers are responsible for defining what the product is and who it serves. They must also determine how the product will drive business impact. Success is to deliver the right value at the right time for the right people.

Value, quality, constraints

Product initiatives have three goals:

1. Create customer value that drives business impact.
2. Build in and maintain quality to enable the team to develop at speed forever.
3. Deliver within given constraints: people, time and scope

Companies often want to keep all three goals fixed. Because change is inevitable, this leads to failure. Unforeseen events occur, which make it impossible to deliver both time and scope. As a result, a product team suffers burn out. Lean (or agile, if you'd prefer) Product teams agree to two of the fixed goals and are flexible on a third -- meaning you can have a fixed time delivery or a fixed scope, but not both.

Determining value

We ultimately create products to solve problems for our customers. In the process of building a product, we work to better understand a customer problem and validate that our software will solve it. Product value is created by enabling positive customer outcomes as a result of using our product, usually through a feature. We prioritize what is most valuable by learning what our customers want or desire, and by determining Key Performance Indicators (KPIs) that meet our business objectives.

Our goal with any product should be to delight the user in the simplest way possible, while also enhancing our margins and differentiate ourselves in the market. For that to work, we need to understand what to build, what not to build, and how to ship value continuously.

Ensuring quality

We define quality in terms of reliability and adaptability. If our customers have a consistently good experience using our product, we can consider it reliable. A product that evolves over time to deliver new value can be considered adaptable. By keeping design and tech debt low, we can maintain a high level of quality in our products.

Constraints

A constraint doesn't reflect an actual product goal, but they are important nonetheless. They can function as guardrails for the team by establishing clear expectations about delivery. Remember, we aim to only satisfy either time or scope in an engagement. Meaning, you can set a list of outcomes for a Minimum Viable Product (MVP). Or you can ship an MVP by a set release date, but the outcomes delivered in that time frame are variable. We don't promise both constraints because that sets us up for failure. Realistic expectations are important.

We manage our product backlog using Pivotal Tracker. Pivotal Tracker is the agile project management tool built by Pivotal Labs. Pivotal Tracker is but one of many product backlog tools. We're not prescriptive about what tool you should use, but we've had success with Tracker.

What to expect from a backlog tool?

Your backlog software should function as the central repository for upcoming work and a historical record of development history.

Tracker Specifics

1. USER STORY: A story is something that a user wants. Stories can be grouped together by Labels or epics
2. DONE: These stories have been implemented by the development team and accepted by the Product Manager.
3. CURRENT: These stories have been picked up by developers and are in various states of implementation. The story status is updated as the story is picked up and delivered. Tracker totals the points for all the current stories into a team velocity.
4. ACCEPTANCE & REJECTION: If the functionality matches the acceptance criteria outlined in the story, you should accept it. If the functionality does not meet the acceptance criteria, reject the story and add a comment explaining what is incorrect or missing.
5. BACKLOG: The backlog contains stories that are ready to be estimated or worked on. The story in the top is the next story that will be implemented. Stories are prioritized based on what will add the most user value.
6. ICEBOX: These are stories that need more thought and detail. The content of the icebox does not need to be prioritized.
7. EPICS: These are considered over-arching themes or outcomes that many stories apply to.

Agile development consists of a continuous feedback loop. Each story has a workflow from conception to release.

Why?

Agility comes from frequent feedback. Story acceptance, rejection, and release gives you the opportunity to give feedback to and get feedback from your customers, your team, and your stakeholders.

1. PRIORITIZATION: The Product Manager prioritizes stories in the backlog.
2. ESTIMATION: The team discusses and collectively estimates each story.
3. STORY START: Developers pick up and begin work on the next available story.
4. STORY IS FINISHED: The developers commit all code changes to the project repository and finish the story.
5. STORY DELIVERY: The committed code changes go through Continuous Integration (CI) testing. When CI tests pass, the code for the new feature is deployed to the team's acceptance environment, and the story is delivered.
6. ACCEPTANCE: The Product Manager reviews delivered stories against their acceptance criteria. If a story is complete, the Product Manager accepts it. If a story is incomplete the Product Manager rejects it.
7. PRODUCTION RELEASE: The code for the accepted stories is pushed to the team's production environment, where users can interact with the new features.
8. REPEAT: Based on user feedback, input from the business and what we learned from our previous product release, the Product Manager determines what to prioritize next.

Knowing what to do next is one of a Product Manager's most important skills. An effective product plan is made up of many small, independent user stories. This allows you to plan and easily respond to change.

The product manager as planner

The Product Manager is accountable for planning the work efficiently. This means:

• Taking a large scope of work and breaking it down into manageable steps to complete it.
• Allowing focus on completing the next priority in the list.
• Seeing progress and the big picture.
• Knowing how to prioritize, estimate and organize stories and track team velocity is fundamental to good project planning.

All stories must be prioritized

Guided by input from users, stakeholders and the development team, the Product Manager weighs user value, business value, development risk and dependencies against each other to determine the priority of a story.

A story's position in the backlog reveals its priority; the most important story is at the very top while the least important story is at the bottom. This makes it obvious which task the team will work on next.

A story's priority can change as we learn more about our user or business priorities change.

User stories must be estimated

All user stories need to be given a point estimate before developers can work on them. New stories are discussed in the weekly IPM. Once everyone understands the purpose of the story and agrees on the simplest way to accomplish it, the team can agree on its size. As each story is a placeholder for a conversation, the IPM discussion may affect changes to the way the story is written.

Knowing the relative complexity of stories helps the Product Manager prioritize and set expectations with stakeholders.

For instance, you can decide to prioritize one big story or three small stories. The amount of work should be the same but the Product Manager decides which story is a higher priority. It's important that the team focuses on complexity rather than effort, as the points are ultimately a planning tool rather than an exact time estimate.

Bugs and chores are not given point estimates. The idea is that these two story types emerge over time, and while they do take time to address, bugs and chores are an ongoing and fairly consistent cost.

Larger stories are grouped into epics

A group of stories that represent a larger outcome is called an epic. Epics convey the overall big picture priorities.

Velocity is a measure of average delivered story points

Average velocity is an indicator of how many points a team can be expected to deliver in a given iteration. It is calculated by averaging the points delivered in previous iterations. Only completed stories count toward velocity. This is one reason why regular story acceptance is important.

When your team gets good at building up features with small, consistently-sized stories, your team gets better at delivering about the same amount of work each iteration. With lower volatility, your team's velocity becomes a more useful planning tool. The iterations planned into your backlog reflect past reality and are useful predictions.

Respond to change

When building software it's impossible to gather all the requirements up front. Responding to change requires knowing how to re-prioritize, estimate and organize stories.