Your head is likely spinning at this point with the daunting challenge of implementing the teachings of this book in your organization. For those lower in an organization, the AccuWiz vision may seem like an impossible dream. Change can be implemented with the aid of an incremental project plan that builds on small successes using the organizational behavior model to influence and sustain change.

There are eight steps to implement your Investment roadmap:

1. Organizational support
2. Stakeholder value analysis
3. Stakeholder research
4. Stakeholder interviews
5. Investment candidates
6. Initial roadmap
7. Investment planning
8. Consequence alignment

The objectives are to establish an initial Investment backlog and roadmap and then instill the practices necessary to manage it. The initial steps can be accomplished without risk and minimal use of resources to establish credibility and support for the overall initiative.

16.1 Step 1: Organizational Support

There are three key decision‐makers in your organization who must come onboard. They are the product management leader (VP/director of product management), engineering leader (VP/director engineering or CTO), and your PMO leader if you have one (head of program or project management). If you are lower in the organization, there may be several management levels that you need to get on your side before getting to these higher‐level positions.

Everyone is suspicious of the person who has just experienced an epiphany from reading a book or attending a seminar. Most people can't contain their excitement and overwhelm others by condensing what they learned over days or weeks into sound bites. You can take a strategic approach to influence decision‐makers with your new insight into organizational behavior principles.

Some say that people are naturally resistant to change. I disagree. If I were to give someone one million dollars, would they be resistant to that change? Of course, not. People resist change when they anticipate negative personal consequences. We know that positive consequences can be used to reinforce the desired behaviors necessary to support change. So don't expect that just evangelizing in terms of general and longer‐term nebulous consequences is going to get you anywhere. You want to identify the frequent consequences for the key decision‐makers.

I recommend you start by understanding and addressing the organizational consequences for product management, engineering, and project management leaders from whom you will need support. The key point is that whenever you are “selling” the idea to anyone, it should be in terms of the consequences they experience on a daily or weekly basis, not how the idea benefits you or the organization.

Although you may not like the term “selling,” this is what one must do to gain support for a major initiative. We know from marketing that people will buy when a product or solution provides a benefit or reduces a pain point. You can now recognize that benefits create positive reinforcement, whereas pain points are negative reinforcement.

Pain points tend to work better at higher levels in the organization because losing one's position is the overwhelming negative consequence (sadly, this often means that the best management tact is to lie low and do nothing!). I also think people react more quickly to reduce pain points. It's probably related to our strong survival instincts. The ability to reduce a significant pain point will spur purchasing behaviors.

Table 16.1 provides typical pain points for individuals in a product development organization and how the Investment model addresses each of them. They also provide an example of how the organizational behavior model can be applied to roles within your organization to understand and change behavior.

16.2 Step 2: Stakeholder Value Analysis

A preliminary stakeholder analysis is a low‐effort, low‐risk next step. It will likely show that product management is so deep in functionality that they miss customer value. You can facilitate this yourself if you are a product manager. If not, propose a morning or an afternoon session that can be facilitated by a product manager. Product management can learn a useful technique for getting down to core customer value. The process enables product managers to get above mundane feature‐level requirements to generate customer value as professional product managers. It's a small investment in time with the potential for very high payback. The benefits of focusing on value should become apparent.

The facilitating product manager should read Chapter 6 of this book. Study the examples and use the same categories and stakeholder table formats (e.g., internal versus external stakeholders). Invite senior engineers to let them contribute to Investment planning.

Start the meeting by creating a complete list of product stakeholders using the categories in the examples. The rules are the following:

• A product stakeholder is a role that gains benefit from your product.
• Include constrainers who can influence or impose requirements.
• Define stakeholder classes for those with the same role and different requirements.
• More is better at this point. Stakeholder roles can be collapsed if the values and requirements turn out to be the same.

The initial experience will reveal that engineers and product managers are challenged to think in terms of value instead of functionality. Most of the initial value suggestions will be functional requirements. Here are some examples from sessions I have facilitated:

• “I want additional reports to see late invoices.”
• “I want a stable system to integrate with.”
• “I want faster response time to get my work done.”

The flag here is that they all imply functionality. They are not at the level of value. Further discussion and application of the “Five Whys” lead to the underlying values:

• “I want to reduce outstanding cash balance to meet or exceed my performance objectives.”
• “As a partner, I want to maximize our integration profits.”
• “I want to achieve higher throughput to meet or exceed my performance objectives.”

The above are good examples of the difference between user stories and epics. Value statements are higher level than user stories. They are like epics, but they relate to business or individual performance objectives – the root driver of organizational consequences.

The key to successful facilitation is to continually screen value statements in terms of the following characteristics to know when you have reached the underlying value:

• Not a feature or requirement
• Does not imply or constrain implementation
• Supports business or personal performance objectives
• Is measurable

It takes some practice, but persistence and continuously cross‐checking with the above-listed criteria will get you there.

My experience is that participants are initially struck by the sheer number of job titles to which their product adds value. They usually find that the values of internal stakeholders who support the product were not being considered. They also see that the values are different at each job level and are usually supportive of the next highest level. Satisfying the value of an influencer can create customer evangelists for your product. However, the attendees recognize that product success depends on ultimately addressing the values at the executive level with a proxy business case described in Chapter 10.

Focusing on the values of each stakeholder guides a deeper level of discussion and leads to common understanding. You will likely hear many comments of, “I didn't know that.” Product managers are often surprised by the stakeholder values contributed by senior engineers who have worked on the product for years. Engineers often feel that a veil of secrecy has been lifted with new access to market and customer information.

The stakeholder value exercise results in a concise picture of opportunities to add value for which customers will be willing to pay. Just as importantly, the exercise reveals information that should be known but isn't. This provides the basis for stakeholder research and interviews described in the following sections.

The session output can be shared as a living document for engineers and product managers. Stakeholders and their values don't change frequently within a market segment. What a great way to onboard new product managers and engineers to rapidly sensitize them to your market and customers.

The last word of advice is that you should consider using a professional facilitator and provide them with the stakeholder value criteria to lead the discussion.

16.3 Step 3: Stakeholder Research

This step involves more resources. The work can be done on a part‐time basis without impacting business commitments by using effective positive reinforcement. Presumably, stakeholder analysis has produced sufficient intrigue to gain support from above. Presenting the results of the stakeholder analysis to the key decision‐makers can garner executive‐level support to provide the resources.

The stakeholder analysis will likely identify large gaps in customer and market knowledge. As opposed to general untargeted market research, a product manager can now focus on specific stakeholder values. Most product managers are surprised at how much information can be mined from the web with focused searches. The trucking proxy business case used earlier in the book showed that I could quickly find detailed data on US trucking operational costs. Credible data can often be found on the web, or reports can be purchased from market analysts. Start with the Key Performance Indicators (KPIs) and stakeholder values of the key decision‐makers.

You may want to pair each product manager with a senior engineer who has product interest beyond implementation. Doing this sets the tone for business and technical collaboration fundamental to the Investment model and demonstrates the value of technical input early in product planning. Recognize that being involved at the business level will not be of interest to many engineers. Many want to remain technical. You can usually find senior engineers who view involvement in planning as career development or have just been dying to have their product ideas heard. Market awareness and business involvement can be criteria for your technical ladder. Engineers can grow in both business and technical directions without having to become product managers who soon become technologically stale. You may even consider a title of “Product engineer.”

The other purpose of this research stage is to prepare for stakeholder interviews in the next step. Interviewers should be able to show that they have done their homework before taking a stakeholder's valuable time. Preparation of questions to fill in the gaps will result in a more concise and effective interview.

This section began with the importance of effective positive reinforcement to engage product managers and engineers. Set up weekly review meetings where the teams can present what they have learned about stakeholder value. Be sure to recognize incremental progress.

16.4 Step 4: Stakeholder Interviews

Identify a subset of product stakeholders who can provide insight into how a specific value impacts their success. Prepare a set of questions based on the research done in the prior step.

Drill down with the “Five Whys” technique to the point where value can be measured. Steer the discussion to value when functionality comes up. You've reached your objective when you can recite a few simple value statements that do not constrain functionality. Stakeholders will usually respond with an enthusiastic “yes” when you hit the mark.

16.5 Step 5: Investments

This is the fun part – an opportunity for creative brainstorming. A half‐day meeting is set up with the participants in the stakeholder value exercises and anyone else you feel could contribute ideas. Again, business and technical fusion is important. Consider inviting others outside of product development, such as operations, support, or IT. The only requirement is that they have reviewed the stakeholder value analyses and the stakeholder interview presentations.

There are numerous brainstorming techniques that can be used, like storyboarding and mind mapping. There may be a common approach used in your organization. If not, bring in a professional facilitator for the meeting. I'm always impressed by how a good professional facilitator can lead a group to creative results without being familiar with the domain.

The purpose of the meeting is to identify opportunities to significantly increase stakeholder values. It starts at the top with the decision‐maker values and then proceeds to the influencers. Recall our definition of great products introduced in Chapter 6:

The common trait of “great products” per Brooks' definition is that these organizations focus on something their stakeholders' value and move it a mile rather than moving everything an inch at a time with features and small enhancements.

The best possible case is that you move a key decision‐maker value by a mile to differentiate your product. However, that's not always possible. The next best thing is to provide a quantum leap in value for one or more influencers. For example, spreadsheets weren't originally justified based on bottom‐line savings. They provided a leap in value beyond methods currently available to create a groundswell of support.

Each value should be examined for the potential to “hit one out of the park” to encourage out‐of‐box thinking. You may not find one, but the ideas generated will often lead you to solutions with value customers will pay for.

16.6 Step 6: Initial Roadmap

The initial roadmap is a challenging step because resource availability for Investments must be reconciled with current business commitments. Your sales and operations stakeholders should be involved because trade‐offs will need to be made between current roadmap targets and the Investment candidates. There will likely be pressure to include all the Investments as well as current commitments. This is where the value of the Investment approach is demonstrated. Your stakeholders will realize that they can benefit more from shorter development increments with higher value.

Start by making any changes in rank based on the updated WSJF values determined during Investment planning. Establish a payback period target if one doesn't exist. Two years is a good starting point to minimize risk. The downloadable Investment Income Profile Calculator spreadsheet can be used to calculate the annual income profiles based on Investment payback periods and development costs for each Investment.

16.7 Step 7: Investment Planning

Investment planning starts only for Investments that fall within the Investment backlog one‐year WIP limit. Planning involves completion of the Investment planning template introduced in Chapter 10. The key is to break it down into small increments as weekly goals for Investment owners. For example:

Week 1

• Proxy business case

Week 2

• KPIs
• Stakeholders
• Constraints
• Competition
• Acceptance criteria

Week 3

• Go‐to‐Market plan

Week 4

• Financial and development cost targets
• WSJF update

Week 5

• Assumption validation

Establish a weekly meeting with the Investment owners to allow them to present. Provide feedback and recognition.

Investment WSJF values are then updated based on the knowledge gained from completing the Investment templates. Investment timeboxes can be updated to provide reasonable schedule targets that incorporate sufficient feature contingency, as described in Chapter 7.

16.7.1 Agile Roadmap Alignment Meeting

The Agile roadmap is managed with the stakeholder alignment cycle depicted in Figure 16.1.

This is the basic cycle used to achieve schedule and financial targets. The meeting should be weekly, or at least biweekly. Any changes that would impact baseline schedule and/or financial targets are identified by the Investment teams. They must present a comparison of any financial impacts with the baseline target. The team may be asked to go back and look at alternatives, such as dropping or simplifying features to stay on target.

The meeting is an important synchronization point to maintain roadmap stakeholder expectations. Even if change doesn't occur weekly, it's good to verify that assumptions are still valid. This is also an opportunity to raise risks that can be addressed proactively. The meeting would typically be led by the product management leader or P&L owner, and attended by project management, sales, and operations leaders.

Investment owners also present their feature burndown projections and financial forecast at each meeting. The following presentation template can be used:

Slide 1: Investment Summary

• Changes from last week
• Financial impacts

Slide 2: Mitigation

• Actions taken to minimize impacts

Slide 3: Alternatives and Recommendation

• Feature content or functionality reduction?
• Additional resources?
• Increased income?
• Investment delay?

Slide 4: Assistance

• Support required outside of team authority

Each alternative should include overall roadmap impacts, including cascading delays and associated Net CoD to facilitate decision‐making. A recommendation may be accepted or a recovery plan initiated. Any changes will be incorporated into the baseline roadmap only after the stakeholders agree on the changes and the financial and/or schedule impacts for the next review.

16.8 Step 8: Consequence Alignment

Most organizations include “alignment of recognition and rewards” in their change management plans. Unfortunately, this usually just involves individual performance plans. We know from the behavior model that performance reviews have limited impact because consequences are long delayed. The Investment approach has been designed with an understanding that frequent positive consequences must be built into the work itself.

You will recognize that the roadmap alignment meeting incorporates a rapid consequence feedback loop. Additional features must be justified in terms of positive financial impact relative to the cascading roadmap Net CoD impacts. Dropping lower‐value features will shift income forward in time. For the first time, you can demonstrate how sales and operations can increase income by reducing features and functionality, moving closer to the illusive Minimum Marketable Feature Set (MMFS).

The roadmap meeting should be a collaborative and supportive meeting as opposed to what happens in many project reviews. The product management leader is responsible for maintaining an environment of positive reinforcement for Investment and technical owners. Presenters must see their management as empowering and supportive. Don't use the meeting to punish. If there are performance concerns, that's a private discussion with an individual's manager.

This may involve a significant behavior change on the part of the meeting leader to move from the left to right side of the motivation curve presented in Chapter 13. Those leaders who have attained success by getting results from negative reinforcement may find it difficult to change.

I hope the behavior model has convinced leaders that they must choose one side or the other to get organizational results. This takes strong leadership qualities. A strong leader will shield people from negative consequences. The leader should not expect to get the results described in this book if they are not ready to establish strong and frequent positive reinforcement in the daily work in their organizations. Empowering people without motivation reduces performance.

There are some methods that the meeting leader can use to help them make this transition. They can appoint a trusted individual who works for them to observe and provide feedback on the extent to which they are effectively applying consequences. It should be someone capable of providing frank corrective feedback after meetings in which they observe any resurgence of negative consequences. It could be an assistant who attends meetings to take notes.

Not everyone will be comfortable with asking for feedback from subordinates. That makes the change more challenging. Alternately, they can keep score during meetings by marking a note pad with an “x” for every time they apply threats or punishment, and a checkmark for positive reinforcement. Maintain a log with an objective of increasing positive reinforcement and reducing negative behaviors over time.

You won't have to do this forever. You will receive positive reinforcement for applying positive reinforcement when you see the results from increased engagement. As we know, positive reinforcement shapes behaviors that become habits.

Positive reinforcement needs to become the natural way of interacting with people you want to motivate. Some guidelines:

1. Be specific so people know exactly which behavior is being reinforced. The impact of positive reinforcement is increased when people know that you know what they did, instead of the often meaningless “good job.”
2. Reinforce during or as soon as possible after the desired behavior or result.
3. Use metrics and charts as opportunities to reinforce. Shorter and more frequent goals provide more opportunity for positive reinforcement.
4. Be sincere – don't say it if you don't mean it. People know.
5. Apply negative reinforcement sparingly to get a behavior started and then positively reinforce the new behaviors and/or results.
6. Personalize the reinforcement. For example, public appreciation may be punishment for some individuals where a personalized e‐mail can be very effective.
7. Forget rewards – only a few people can win (usually the self‐motivated), while others are often disgruntled. You need to motivate the unmotivated using positive reinforcement to achieve high organizational performance.

These are all good techniques to increase the effectiveness of your positive reinforcement, but they don't replace the need for a leader to establish the environment for peer reinforcement. Consider the time spent interacting with your staff compared to the time they are working with peers. That's where positive reinforcement can be the most frequent and meaningful.

The roadmap alignment leader must be aware of how the behavior of others add to or subtract from positive reinforcement in the meeting. Punishment from an attendee can extinguish the effect of positive reinforcement. Be prepared to provide corrective feedback to attendees as needed after the meeting. It may even require removing certain people from the attendee list.

We've discussed consequences for Investment teams in the roadmap alignment meeting. What about the individual product managers and engineers working on an Investment? The good news is that if you have implemented the practices provided in this book, you will observe collaboration and teamwork. Product managers and engineers now have common goals for Investment schedule and financial results. Common goals foster collaboration, teamwork, and peer reinforcement.

Whether or not you are using Agile development, you need to create winners in your organization. You can't make a team act like winners. They must be winners to act like winners. Put an event on your calendar as the first thing you see at the start of every week with the following note.

What opportunities have I established this week for peer recognition for achieving shared objectives?

If the answer is, “none,” you are unlikely to ever see the incredible power of high‐performance teams.

16.9 Summary

1. Gain organizational support for change initiatives by addressing the pain points of influencers and decision‐makers.
2. Start with a low‐effort analysis of stakeholders using the methods described in this book. The exercise will provide valuable customer and market insights.
3. Market research can now be focused on specific stakeholder values.
4. Generate a potential list of Investment candidates. Use the point system to prioritize Investments based on WSJF.
5. Free committed resources where possible by using Net CoD to show financial benefit of dropping low value features.
6. Let the Investment owners create weekly targets for detailed Investment planning for Investments within the one‐year WIP limit. Recognize progress.
7. Establish the Agile roadmap alignment meeting with roadmap stakeholders to frequently collaborate and synchronize expectations. Financial and schedule impacts of changes are reviewed before acceptance.
8. Assign program managers at the release level to achieve release business objectives and to minimize release opportunity costs.
9. The Agile roadmap meeting leader must accept the need to move to the strong and frequent positive reinforcement side of the motivation curve.
10. The positive consequences to motivate self‐directed teams are inherent in Agile development freed from the constraints of Waterfall planning. Just support Agile the way it was envisioned.