IN THIS CHAPTER
- Diving into waterfall and Agile development
- Making product trade-offs
- Following important leadership practices throughout development
You’ve got a great idea that meets all the criteria for success. Y our plans are in place, and your development team knows who the personas are (see Chapter 5 ), understands the use cases (see Chapter 11 ) and/or user stories (discussed later in this chapter), and is ready to build a great product. Now the work of creating that great product begins, and you as the product manager need to step up and lead the team through any bumps in the road that come up.
Getting the Lowdown on
Waterfall/Phase-Gate versus Agile
The two general development methodologies used for developing products are waterfall
and Agile. Waterfall is a phase-gate (also called stage-gate) process (see Chapter 3 ), and Agile comes in many flavors, such as scrum, extreme programming, Lean, and kanban. We cover the key principles of waterfall and Agile in regards to product management here so that whatever method you choose (or is chosen for you), you can be successful.
Waterfall: Measure twice, cut once
The philosophy behind waterfall development is that you do all the planning up front in
large batches. Product managers give developers an inclusive list of features and market
needs (see Chapter 11 ) from which developers can build a completed product for release. Development in waterfall can take six months, a year , or even several years.
The waterfall approach is typically used for physical products, large-scale software
releases, and products that have very strict regulatory or other legal requirements. It
works very effectively for products where requirements, the market, and competition
don’t or won’t change often.
In waterfall development, the product manager delivers a market needs or market
requirements document (MRD) before development starts. The MRD includes everything
about the market, personas, use cases, customer and market needs, window of opportunity , and anything else the engineers need to completely develop the product. It’s often a formal document that key stakeholders (such as management, development managers, the product manager , and anyone else in the company that will be affected) have signed off on.
Only after sign-off of the comprehensive MRD in the plan phase does development then
begin. See Figure 12-1 for a look at the progression of phases.
The advantage of waterfall is that the product manager can take an extensive amount of
time to put forth a carefully thought-out MRD. It avoids the company’s rushing to market
and potentially building features that may be trendy this month but meaningless in the
long-term. It also avoids asking engineering to change priorities constantly; under
waterfall development, everyone has to get on the same long-term page. The product
manager has more time for strategic planning and for maximizing the overall success of
The disadvantage of waterfall is that it lacks the flexibility to change plans because the
MRD has to be revised and the stakeholders have to be informed of the changes, agree to them, and sign off accordingly . Thus, new features can’t be added easily , and they aren’t delivered to customers as rapidly as they are in Agile since the planning and release cycles are much longer with waterfall. Market and customer needs may change during development, and with waterfall, the team can’t respond quickly .
Agile: Plan and deliver rapidly
Agile is the opposite of waterfall (which we discuss in the preceding section). Agile
development uses a lot of very specific terminology . You may hear terms such as scrum, scrumban, kanban, and extreme programming (XP) to refer to different developmentmet hodologies. The most common Agile development framework in use is scrum, which is the one we focus on here; Figure 12-2 shows its structure. Agile is excellent for software products, especially for smaller applications, software as a service (SaaS), and web-based applications.
Sprinting to the finish
Under scrum, development occurs in short, defined periods called sprints, which are up to two and no longer than four weeks long. The goal of each sprint is to create code in an
iterative and incremental way and complete a particular piece of work. This process is
repeated (iterated) while the product is progressively built (increments).
For each sprint, the development team takes work from the top of the product backlog
(discussed in detail later in this chapter) focusing on the top priority items that can be
developed during the allotted time. The team breaks down the work for each sprint into
tasks and then executes each task. Quality assurance occurs in parallel (simultaneously). If a task won’t be completed in its given sprint, it’s pushed out to the next sprint.
However , each sprint can be released to customers as soon as it is complete. Alternatively , several sprints are often bundled together and provided to customers in a larger product release. Figure 12-3 shows the cascading relationship between tasks in a sprint, sprints, and a product release.
Telling (user) stories
In Agile, you communicate the requirements through simple user stories to the engineers instead of writing and signing off on a comprehensive MRD as in waterfall. User stories can be simply written on a 3-x-5-inch notecard, or they can be captured electronically in a database or Agile development software system. The focus is on communicating and working as a team while minimizing documentation. The user stories convey to the engineer what the customer need is and what the user is trying to accomplish. Once the engineer has discussed the user story with the product manager or product owner and fully understands the meaning of the user story , the engineer then builds the feature.
The format of a user story is as follows:
As a <persona> , I want to be able to <customer need> so that I can< benefit of requirement>.
Figure 12-4 is an example of a user story
Creating the backlog in Agile
To understand how the entire product is eventually divided into user stories, you need to
start up at the top with the overall scope of the entire product and work your way down
into the details of the user story . Two key tools you use are story mapping and product
Story mapping is a technique, developed by Jeff Patton, of mapping out the particular
activities that need to happen in the product to make sure a customer accomplishes her
goal. The wonderful thing about a story map is the clarity it gives you and your
development team about what completely addressing a customer need will take. In the
best case, you bring everyone together in one room and work the story from beginning to
end. The process generates significant learning and understanding on all sides, which
leads to less confusion for the duration of the project.
To create a story map, you can use sticky notes, markers, dots, colored masking tape, and a blank wall space. In Figure 12-5 , you can see how you start by creating a backbone of user activities at the top. These can be logging into the software, selecting a product, and going through the check-out process. Under each of these activities are tasks (not necessarily the same as the tasks which drive development work within a sprint). Under each task, the development team fills in all the subtasks, user interface, and other details that the user needs to complete the tasks. Once all the development tasks have been documented, the list of tasks is divided into what absolutely must be done to bring the product to market. This first slice is your minimum viable product. The work done in future releases is allocated to the next slice.
Prioritizing the backlog
As we know , in Agile, the basis for a development team to create a working piece
of software is a user story . It’s the smallest block of development. The next size up is a
feature. And even larger is an epic. (In Europe, the term for an epic is a saga. ) So
remember: user story < feature < epic.
Here’s an example of an epic, feature and user story for an online store selling shoes. The epic has a larger scope of work than the feature which is again, more work than the user story . The user story is the smallest slice of work that the product manager typically works with.
- Epic: As a customer , I want to be able to purchase shoes online so that I easily compare a wide range of shoes from the comfort of home.
- Feature: As a customer , I want to be able to purchase the shoes I have selected so that I don’t have to look around a lot of shops.
- User story 1: As a customer , I want to be able to pay by a range of most commonly used credit card options so that I can choose a convenient payment option.
- User story 2: As a customer , I want to be able to input the city where the shoes will be delivered so that I can receive my shoes.
User stories 1 and 2 both address parts of the feature, but not all of it. And the feature
addresses some of the epic but again needs other features to complete all aspects of the epic.
As you can see in Figure 12-6 , your product backlog consists of many of these user stories, features, and epics. As you investigate proposed development work, you realize that some work has more customer value than others. This work should then be done earlier . The reality of development is you simply can’t get to the level of detail needed for the entire product upfront. You would spend a huge amount of time upfront in development breaking down each and every piece of work to be done while developers twiddled their thumbs.
Instead, you prioritize the proposed work by customer value and create a prioritized
product backlog, most often referred to as a prioritized backlog or more simply backlog.
At the top of the backlog, you have your user stories that the development team are just
about to start with; below that are your features and then your epics. As features and epics come to the top of your backlog, you break them down into user stories that your
development team can work on.
So what do you work on first? A lot depends on what you’re building. If you’re just starting out, building out a software structure or architecture for what comes later is usually most important. For an ongoing product, the items at the top of the backlog are most definitely what has the most value both to the customer and your company . The reality is that sometimes you have to prioritize a bug fix or solve a larger structural issue with the software, which is referred to as technical debt.
The beauty of a product backlog is that one person is in charge: the product owner (or
product manager in the role of product owner). That is an absolute within scrum. This
person decides what the development team works on next. That said, it would be a poor
product owner who didn’t get feedback to make sure that the development team lets her know what would make most sense to complete next.
Documenting the product backlog
The issue with tracking an Agile backlog is that the volume of information is huge. Most
teams move quickly away from documenting each piece of information with index cards
and switch to software written for this purpose. A side benefit of using software tools is
that tracking is integrated so it’s also easier for you to figure out what stage each piece of work is at. When you know what software your development team is using, spend the time to learn all the ins and outs so that you can use it to efficiently document the product backlog.
Invest in features
When you write down your product features, a good rule of thumb to see if you’re headed in the right direction is to use the acronym INVEST (kudos to Bill Wake for this idea). Table 12-1 tells you all the aspects of a good product feature or user story . The “small” rule is critical to Agile only . The rest are applicable to both waterfall and Agile requirements.
TABLE 12-1 INVEST in Good Features
|Independent||Avoid dependencies between features and user stories.|
|Negotiable||User stories are reminders to collaborate.|
|Valuable to the customers||Avoid requirements that have only technical value.|
|Estimate-able||Can estimate how long it will take to complete.|
|Small (Agile only)||The requirement should take no more than two days to complete.|
|Testable||The requirement has defined acceptance criteria.|
When is a feature really a constraint?
In creating a product, you sometimes have features or user stories that are really hard to
write. They don’t seem to fit into the usual user story pattern. These are better written as
constraints. For example, how long should a task take? What operating system(s) should it operate under , or what temperature range should it operate within? Simply write down the limits of what the product needs to do without reference to a customer and move on.
Examining Agile’s manifesto and key principles
Agile in all of its different forms was created based on the principles stated in the Agile
Manifesto, shown in Figure 12-7 . The Agile Manifesto was created by a group of software developers who were looking for a more optimized way to develop products and bring features to market faster . Over time Agile has started to be applied to many types of products beyond just software.
Agile has 12 key principles shown in Figure 12-8 .
SPEAKING THE SCRUM VERSION OF AGILE
Agile development using the scrum framework has a lot of very specific language (check out Scrum For Dummies by Mark C. Layton [Wiley]). Here are a few additional terms you may encounter . Figure 12-2 may help in giving you context for the different sprint meetings.
- Sprint planning meeting: Happens at the start of a sprint. The product owner and the team first decide on a sprint goal. During the meeting, the product owner describes each user story , and the team then asks questions and plans the group’s work for the sprint. Don’t confuse sprint planning with the product management planning activity . Sprint planning focuses on the work required to complete the user stories the team committed to for the sprint. Product planning is a strategic activity that provides long-term direction and spans an extended time period.
- Sprint goal: A brief one or two sentence description describing what the Agile team is planning on accomplishing during the sprint.
- Daily scrum: The daily synchronization meeting that takes place within the team.The team includes all the engineers. Product owners and scrum masters are optional attendees. Each person stands and answers the following three questions: What did I do yesterday toward the sprint goal? What will I do today toward the sprint goal? What’s getting in the way of me doing my work to achieve the sprint goal?
- Sprint review: Meeting at the end of a sprint where the product owner reviews the sprint goal with key stakeholders and has the engineering team demonstrate the completed product increment.
- Sprint retrospective: A separate meeting from the sprint review; it can exclude anyone outside the development team. Typically , product owners join this meeting. During the meetings, the team reviews lessons learned and improvements that can be made. Ideally , the team commits to making at least one change in the way that they work.
Assuming typical responsibilities
Whether you’re working with a team doing waterfall development or Agile development,
getting clarity on the roles and responsibilities of each of the team players is critical.
Typical responsibilities for the product manager include the following:
- Acts as a market expert
- Defines and drives strategy
- Owns the product vision and road map
- Bridges the gap between engineering and marketing
- Develops and creates the business case
- Presents customer needs
- Makes feature, schedule, and cost trade-offs
- Brings products to market
- Is responsible for value delivery through business ecosystem
- Is responsible for all aspects of product success
Typical responsibilities for the product owner are these:
- Is responsible for managing and ordering the product backlog
- Optimizes the business value of the development effort
- Ensures product backlog is visible
- Ensures the development team understands each item in the backlog to the level needed
- F acilitates setting the goals for each sprint
- Is available to the development team at all times
Unlocking the Secrets of the Product
Development Trade-Off Triangle
Product development involves a well-known concept called the development trade-off
triangle. Figure 12-9 shows the trade-off choices: features, quality , and schedule. The idea is that you can aim for two vertices of the triangle, but three is usually unattainable. If you want more features and want to keep the schedule fixed, you need to lower quality . If you want more features, and want to keep quality fixed, you have to increase the amount of time for development and slip your schedule. And if you want to shrink the schedule, you have to give up scope or quality . The challenge is to make these trade-offs in the best possible manner so that the best product ships as close to schedule as possible with the features that it needs to be successful.
The bottom line in terms of the triangle is that no set formula exists for making these
tradeoffs. Making a decision on what to give up is highly dependent on your product’s
situation. You as the product manager have to constantly monitor the team’s progress, get feedback from your testers and the competitive environment, field pressure from your management, and account for other factors; and make the most informed choice that you can.
In a waterfall development environment, the trade-offs are typically more difficult
than when doing Agile development because all the planning takes place upfront and
development then occurs on a long schedule. Having the schedule and release dates
already set far in the future puts pressure on keeping to the original schedule. This
time crunch pressure leads to sacrifices in quality or a reduction of features when the
development team can’t deliver what was initially promised. T o add to the difficulty of
waterfall development, additional information is flowing into the product manager
while the product is under development: competitive information and product change
requests from management, sales, and other stakeholders. Adding or changing
features once again adds to a trade-off between the schedule and the quality level.
Often the amount of testing is also at risk. The product manager is the only person in
a position to understand from a market, competitive, and customer needs perspective
what the right trade-offs are between the schedule, features, and quality .
When you’re working with a team doing Agile development, the trade-offs aren’t
necessarily easier; they’re just different. The schedule is usually fixed in terms of the
length of the development, and the quality assurance is built into the sprint schedule. The easy thing to do is simply remove features. In other words, if a feature isn’t ready during the sprint, it simply gets pushed to the next sprint.
One challenge is that if you’re combining sprints to complete a major release, critical
features may not be included because the team ran out of time to develop them. This
scenario can put your product at a competitive disadvantage or make it not compelling
enough for customers to purchase. The product manager and the development team have to plan carefully to ensure that difficult-to-develop features make it to market.
Maintaining Best Practices during
Staying informed and engaged with your team during development of the product is
crucial. Critical questions about how to implement features and what trade-offs to make
come up on a daily basis. As a leader for the product efforts you must step up and be there to help the team do the right thing for the customer .
Depending on the type of product that you manage, you may spend a lot or a little
amount of time in the develop stage. Understanding and then succeeding with your
partners in the journey of product creation is important to your success as a product
manager , regardless of how much time you spend on the task.
Here are a few best practices and tips for being as effective as possible during this phase:
- Make sure you’re easily accessible and available to your team. Often, decisions need to be made rapidly; if the team members can’t ask your opinion, they may proceed with whatever they think is best.
- Continue to monitor the market, competition, and other factors. Communicate what’s going on with customers and the overall market to your team so that they view you as the de facto expert and are able to make the best product decisions. Update your strategy and plans accordingly . You know your engineers view you as the true voice of the customer when they come to you with questions like “Do you think customers would prefer A or B?”
- Whenever possible, use data in all your decisions and communications. Engineers love data and logical decisions, so make sure they understand where your decisions and opinions are coming from.
- Resist the temptation to cry wolf. During development, your salespeople, executives,and others will often come to you with a sense of urgency or panic. They want to change plans, add features, and pull in the schedule. If you react to these requests by constantly asking your team to make adjustments, you lose credibility and eventually severely diminish your ability to lead the team. Save your requests for times when changes are mission-critical. Give thorough explanations to your team if changes need to be made so that team members know that when you ask, it really matters.
- Don’t fall into the trap of wanting to get the product out at all costs. This decision is often based on the assumption that any remaining issues can be fixed easily with a product update soon after launch. It may be tempting as you near the end of development and everyone on the team is tired, but don’t do it. If your product isn’t good enough, you may cause irreparable harm to your product and brand reputation.