The requirements document is where the rubber meets the road for your product’s development. At this point your high-level observations about market opportunities get translated into capabilities by your engineering team. Many different people will contribute content to your requirements documentation. The contents often vary between companies. The following sections are frequently a part of this important document:

• About this document
• Business analysis
• High-level use cases
• Functional requirements
• Compliance requirements
• Report requirements
• User interface requirements
• Environment requirements

Now let’s take a closer look at what’s included in each section.

About this Document Essentials

This section sets the framework for the entire document.  It is vital that it give the date of the last document revision, the version number, and who made the most recent change. In addition, a description of the revision should be given. These specifics will show who approved the changes and the date of the approval. This section is also a good place to define key terms used in the document.

Business Analysis Section

This section is a high level definition of the business need for the new capability.  Here product managers notate the proposed release date linked to the product roadmap. The section lists high-level business and marketing requirements including release dates. A SWOT analysis could be included indicating strengths, weaknesses, opportunities and threats to the project. The last item included is a Feature Matrix, which captures product development estimates for a prioritized list of features. This establishes a firm cut-off line for product development, based on the resources, time, and money available.

High-level Use Cases

Here, you’ll highlight detailed business objectives, which will become functional specifications for the new product. A diagram is often included showing the system with which the user is going to integrate. This system will gain value from the new capabilities you’re developing. If more than one group will use your product, this section is a good place to list all the use cases the team has developed.

Functional Requirements Section

The functional requirements you list will likely develop into something of a use case. It will show behavioral elements of how the product will be used. These requirements are where you’ll reveal specifically what your product is supposed to accomplish. This information will inform and guide the product design.

Compliance 

What does the law require of your product? That will be the subject of the Compliance Requirements section. This section could include data use rules, security or contractual considerations, or perhaps even government requirements.

Report Section

Inputs, layout, report fields, headers and footers, and any groupings are all detailed in the report’s requirements section.

User Interface 

How does one engage with the project? That’s what is explained in the User Interface Requirements Section. The information often consists of a conceptual site map, and is frequently presented in a diagram exploring the analysis that’s taken place. If there’s a protosite to model the user interface capabilities, a hyperlink is given.

Environment Section

Architectural standards that relate to system performance and any operational or integration are presented in this final section of the document.

Taking the Next Step

In my next post, I’ll look beyond the development of priorities, roadmaps, and requirements to explore the importance of remaining flexible throughout the process.

Advancing the Profession of Product Management
website I consulting I training I toolkits I books I blog I twitter

The post Requirements in a Non-Agile Organization appeared first on Actuation Consulting.

Reach Out to the Rank-and-File with Your Product Vision

Step back a moment and enjoy your recent weeks’ accomplishments. You’ve developed a solid product vision and shared it successfully with executives and thought leaders. Now it’s time to broaden your reach and get those who will be actively involved in executing your plans on board. One of the best ways for you to do this is by creating forums for sharing your product vision. Also be prepared to share any high-level support detail that you developed after meeting with customers.

Begin With the Team Leaders

In the influence map exercises we’ve discussed in an earlier post, you identified key people who were critical to your success. Now it’s time to circle back and meet with any team leaders who may not be aware of your plans. A good place to start is with any of your own team members who may not be aware of the plan. Bring these people up to speed then reach out to others in your organization. Some meetings will be one-on-one. At other times it will be appropriate to talk to an entire team or even a larger group at one time.

Engage Your Known Supporters

Think back to when you were sharing your vision with your company’s thought leaders. Who among them were your strongest supporters? Once you’ve identified those firmly behind your plans, enlist them to bring those in their operational area on board too.

It’s important to remember that not everyone will be solidly behind you. Some people are happy with the status quo. Others resist change. Be prepared to face a certain amount of resistance. Keep focused on your goal: to align as many people as possible behind your vision. Invite them to participate in making the vision a reality. The better your team understands where you’re leading them, the more support you will gain.

How Product Managers Should Handle Questions

Don’t dodge questions from employees or try to bluff your way through. As a product manager you’ve done a tremendous amount of research and consulted with customers, executives, and thought leaders. You’ve tried to think of every possible argument against your plan. If someone asks a question you haven’t considered, take the time to find the answer and then get back to this person after the meeting.

Accurately communicating your vision and getting the employees behind your plan is critical to success. With the help of those who share your vision, you’ll be able to win the support of many people across your organization. Ultimately, you are accountable for getting results. But you need others to ensure success.

Advancing the Profession of Product Management
website I consulting I training I toolkits I books I blog I twitter

The post Product Vision: Driving Organization Alignment appeared first on Actuation Consulting.

The Product Manager and the Business Plan

Getting familiar with your organization’s business plan is the best way to fully understand what your organization expects your team and department to accomplish.

Why is the Business Plan so Important to the Product Manager?

The business plan is a document created by upper management that is laser focused on your company’s major business objectives and the logic behind them. Its primary purpose is often to attract investment capital. It can also be a good road map for you as a product manager because it explains how your organization plans to reach its goals. Usually the business plan is shared with senior leadership, potential investors and the board of directors.

What to Do if Your Company Is Reluctant to Share the Plan

You, as a product manager, may have difficulty getting your hands on the business plan. Before you ask to receive a copy, it is wise to determine the company’s attitude toward the business plan. Even if you decide that your company will be reluctant to share the plan, there’s a way you can still get at the information you need. Consider asking for just those elements of the plan that relate to your product or area of the business. Because your management knows that you are responsible for the success of your product, it will likely see the wisdom of sharing this portion of the information with you.

What Product Managers Can Expect to Find in a Business Plan

The more complex your business the more complex you can expect its business plan to be. Most business plans range from 15 to 50 pages. Writers of well-written business plans strive for brevity and clarity. Most plans contain the following sections:

• Executive summary
• About the company and industry
• Market dynamics
• Technology/manufacturing/operations
• Administration, organization and people
• Key milestones
• Risks to the business
• Financial data

Every business plan begins with an Executive Summary. The Executive Summary provides a boiled down view of the key information contained in the plan. It also includes information about what will be sold, the market, the company’s competitive environment and what gives your company’s products or services a competitive edge.

Key financial information will also be highlighted in the Executive Summary along with the financial resources the company anticipates needing and how funds will be spent.

In my next blog post, I’ll explain additional information product managers can expect to find in each section of the business plan and why it is important to them in their efforts to help the organization meet objectives.

Advancing the Profession of Product Management
website I consulting I training I toolkits I books I blog I twitter

The post The Business Plan: Align With Your Organization’s Objectives appeared first on Actuation Consulting.

Is Your Organization Effective At Decision-Making?

In order to get a better understanding of respondents perceptions of their organization’s decision-making aptitude we asked the following question “Do you feel that your organization does an effective job of decision-making in order for the product team to successfully develop products? (Select all that apply.)” Here’s what we found.

Making and sticking with decisions can be an important component of organizational success. Yet,in no category of decision-making represented by our survey answers did more than 50% of survey responders indicate that they were good at making and sticking with decisions.

Furthermore, nearly 30% of respondents (29.7%) report that they struggle with making and sticking with decisions in all areas mentioned in the survey. Product team members perceive efforts in the area of technical decisions most positively giving them the highest marks at 49.6% while perceiving the making of and adherence to go-to-market decisions at the lowest level (29.5%).

Conclusion

The data illustrates that few organizations are perceived as having an aptitude in making and sticking with decisions both tactically and strategically. While more organizations say they do a better job at the tactical aspects of decision-making only 37% indicate that they are good at making and sticking with strategic decisions. Some will no doubt argue that their markets are too dynamic to stay the course with their decisions. However, it is clear that one of the best paths to better performance is to build an aptitude at making and sticking with strategic decisions where it is clear that the majority of organizations, including your company’s competitors, are weak.

How effective is your organization at making and sticking with strategic and tactical decisions?

Advancing the Profession of Product Management
website I consulting I training I toolkits I books I blog I twitter

The post Are Organizations Effective At Decision-Making? appeared first on Actuation Consulting.

To systematically incorporate the voice of the customer organizations have to minimally do three things well:

• Channel the various sources of the voice of the customer into the organization
• Effectively acknowledge receipt of the customers feedback and suggestions
• Centralize the inputs in a manner that makes for efficient decision-making

Let’s look at each of these in turn.

When it comes to channeling the various sources of voice of the customer into the organization product teams can become too dependent upon a single source – for example the sales organization. A myopic approach can yield beneficial input but it’s important to realize that the sales team is not the only or even the best source of customer feedback.

To illustrate this point let’s do a quick exercise. If we had 20 people in a room and I whispered a phrase in the closest person’s ear, and I asked that person to continue to whisper in the next person’s ear until all 20 people had been whispered to, do you think that the phrase I whispered would be the same one after passing through all 20 people? The answer is no, that’s highly unlikely. Each whisper of the phrase degrades the quality of the initial information until it’s no longer accurate or recognizable.

So when it comes to channeling the voice of the customer product managers need to really question if what they’re hearing from sales, or any other intermediary, is actually an accurate representation of customer needs. The more direct the conversation – the higher the likelihood of its value. A better approach is to triangulate multiple sources of (primary and secondary) information rather then relying upon any single source as this allows you to check and challenge what you’re being told.

Which leads us to point two – acknowledgement. With so many inputs available handling the actual acknowledgement of these requests is often problematic. While organizations continuously ask for customer feedback few are exceptional at telling individuals thank you for the input and more importantly how they plan to use or not use this information in their decision-making process. Asking for feedback, and not acknowledging receipt, (other than in an automated way which the customer likely perceives as a black hole) only compounds the problem in the eyes of the customer. However, organizations do this time and again.

Finally, centralizing these inputs into a repository of some type – whether paper-based or automated – is required to effectively rank and prioritize product opportunities. Most organizations tend to rely upon paper or spreadsheet-based processes with varying degrees of success. There are also a growing number of SaaS solutions that offer the opportunity to automate this process. Over the last five years vendor capabilities have continued to improve and they are becoming easier to use and therefore more effective.

Conclusion

Organizations that utilize a voice of the customer approach need to take a hard look in the mirror to see how well they’re handling all three phases of the process: input collection, acknowledgement and centralization. Acknowledgement continues to be the weakest link in the chain but all three areas are ripe with opportunity for improvement.

Not acknowledging incoming suggestions on how your products can be improved can make your customers think you aren’t listening or don’t care — neither of which is good for your business.

How well does your organization handle the acknowledgement process?

The post Voice of the Customer: Why Are Organization’s So Poor At Acknowledging Customer Feedback? appeared first on Actuation Consulting.

Successful product management leaders enjoy the opportunity to shape the future direction of their products and angle the organization toward success. They are also very effective at anticipating obstacles to the teams’ success and mitigating risks that can undermine results.

Yet when you take a step back and look at the number of product management organizations that are truly proactive the number is quite low.

There are a wide variety of reasons why the product management function never achieves a proactive state. These include; continuously changing direction from senior leadership, under-emphasis on the strategic elements of product management (appropriate context), insufficient resources or talent, poor definition of the product management function and/or role, and innumerable other factors.

In order to optimize the product management function product management leaders need to start by providing context for others to understand where product management is headed and also clearly define roles and responsibilities. With the basic infrastructure in place you can take the next step and implement a tool that illustrates that the product management function is a well-oiled machine whose underlying processes are understood and repeatable.

One means of proactively illustrating that your product management processes are under control is to publish an annual product management calendar. A typical product management calender will likely include many of these events:

• Advisory council meetings
• Roadmap planning sessions
• Roadmap publication dates
• Cross-functional team meetings
• Executive steering committee reviews
• Annual pricing and forecasting submission dates
• Annual sales meetings
• Customer events

By publishing a functional calendar you are proactively managing the expectations of your cross-functional partners and stakeholders and helping them more effectively plan their time in support of your shared organizational goals. A calendar also communicates that product management has an established process that underlies these individual activities and that product management’s activities are not random – rather they are well thought out and sequenced to optimize results.

Organizations benefit from clearly communicated information and in the absence of communication it is human nature to fill in the blanks – often in ways that detract from results. If you want to visually demonstrate proactive product management implement a product management calendar.

A product management calendar injects transparency and predictability into the equation – qualities that are highly valued and frequently rewarded by organizations.

Greg Geracie is a recognized thought leader in the field of product management and the President of Actuation Consulting, a global provider of product management consulting, training, and advisory services to some of the world’s most well-known organizations. Greg is also the author of the global best seller Take Charge Product Management. He is also an adjunct professor at DePaul University’s College of Computing and Digital Media where he teaches graduate and undergraduate courses on high-tech and digital product management. 

The post Why Are So Few Product Management Organizations Proactive? appeared first on Actuation Consulting.

Last year’s study illustrated that product managers and product owners are the only parties that stay with a product from its conception until its ultimate retirement. For example, while an organization may have a project manager work in tandem with the product manager, the project manager might lead the project only from the initiation of the project charter until the product or product capabilities become tangible and are ready for launch. This is typically when the project manager rolls off the product development effort to pursue the next project. Meanwhile, the product manager stays the course – continuing with the product throughout the phases of the lifecycle while other functions come and go.

Our regression analysis clearly shows that the more well-defined the product manager’s role is within the organization and the product team, the more likely the team is to be high performing.

How well defined is the product manager role in your organization? The answer may be telling.

Greg Geracie is a recognized thought leader in the field of product management and the President of Actuation Consulting, a global provider of product management consulting, training, and advisory services to some of the world’s most well-known organizations. Greg is also the author of the global best seller Take Charge Product Management. He is also an adjunct professor at DePaul University’s College of Computing and Digital Media where he teaches graduate and undergraduate courses on high-tech and digital product management.

The post How Well Defined is the Product Manager Role in Your Organization? appeared first on Actuation Consulting.

I was recently talking with a peer about the challenges organizations face when rolling out Agile. He mentioned that he was talking to a client later in the day and wanted to know what my recommendation was. I said “in my experience, you have to take an Agile approach to rolling out Agile to an organization.  Agile brings about change, and depending on the culture of the organization, it may take time to fully adopt. An incremental approach is the best way to roll it out.”

He asked, “what if the client wants to rip the band-aid off and roll it out all at once?” I responded half-jokingly “well it depends on how many people they want to leave behind in the process.”

My response was admittedly tongue-in-cheek, however, the more I thought about his question, the more I wanted to modify my initial answer. Rolling out Agile in a big bang approach really seems counter intuitive considering what we’re rolling out. However, rolling Agile out iteratively brings up the specter on how well Agile can scale. An Agile roll-out to an enterprise can involve several hundred people and a large number of cross- functional teams. Should we expect Agile to scale to this level?

I’m finding more and more CIO’s and CTO’s want to take the big bang approach. They want to make the leap – growing pains and all – and they want to make it now! However, the approach taken can make or break its success. Is the best approach in rolling out Agile to an organization done through actually running the roll-out like an Agile project or is a big bang approach better?

I’ve attempted to break down some of the key components of Agile to try and answer this question.

Communication

Increased communication is a key Agile principle. Agile works great with teams of 10-20 people. Because of the smaller team size, most team members actually (dare I say) develop friendships. Agile doesn’t necessarily work when thousands need to interact. Agile just doesn’t seem to be designed to scale.

Lack of documentation

Because of the increased communication, the need to document in an Agile project isn’t really required. Agile is very light weight and is about “just enough” documentation. However, at the enterprise level, rolling out a new methodology (Agile) requires communication to be crisp, coordinated, and concise. Because of the different perspectives, constraints, and cross-functional priorities, a roll-out needs to be managed very tightly. A roll-out of this size requires that things get documented. Again, I would have to say that running an enterprise Agile roll-out via Agile principles doesn’t seem to be the right way to go.

Self- Organizing Teams

The concept of self-managing teams, organizing around goals, works great on smaller Agile teams of 10-15 people. However, an army of people – cross-functionally based and geographically dispersed – requires order to function effectively. At the enterprise level, lack of structure doesn’t lower chaos – it ensures chaos.

All in all, I came away thinking that my instinctive answer was correct. Either path faces challenges. It’s a question of what makes more sense for your organization: rip off the band-aid and endure short-term pain in the hopes of long-term gain; or pilot your way through it in an attempt to manage the risk of disruption, but risk losing support if tangible progress can’t be demonstrated.

An enterprise roll-out of Agile requires up-front planning, clear communication, and structure. Yes, a more pragmatic, iterative (RUP like) approach would seem to be the best way to go. I know I may receive a large number of comments on this one, but dare I say, I recommend running an enterprise Agile roll-out through your PMO.

Regardless of which path you take, be sure to go in with eyes wide open!

The post Is Big Bang the Right Approach to Organizational Agile Transformation? appeared first on Actuation Consulting.

Last week I wrote a blog post entitled Agile Dominance: Fact or Fiction? It quickly rose to the top of our most popular posts. Normally my blogging partner Steven Starke would be doing this weeks post but right on the heels of last weeks post I was sent an article from the Software Development Times. I want to thank Jon Gettinger, CMO at Accept Software for sending it my way.

The article highlights key findings from a recent study that analyst firm Voke conducted entitled  “Market Snapshot Report on Agile Realities.” In fact, the article by Suzanne Kattau recapping the findings was interesting enough that I asked Steven if I could do this weeks post. He was kind enough to let me. The information that Voke published dovetails nicely with my post from last week and helps to round out the findings from our own global study. Here are some of the key findings from Voke’s study.

• Agile development is often assumed to be faster, better, and cheaper than Waterfall – but often proves otherwise.
• Many organizations are immersing themselves in Agile without a clear understanding of what it is and the organizational impact of adopting iterative incremental methodologies.
• Interestingly, the study finds that the cost of Agile software projects are rising significantly.
• Finally, organizations commonly embrace Agile but don’t have a consistent definition of what Agile is. Over 50% of the 200 respondents had a unique definition of what Agile is!

The post What Does Agile Mean to Organization’s Today? appeared first on Actuation Consulting.

Companies often struggle to maintain a good balance between their market activities and their product development efforts. The fact is – most new products are not ready for prime time. This circumstance leads to products that deliver less value than anticipated or fail altogether. The inability of organizations to effectively bring products to market often creates a significant drag on companies’ ability to innovate and compete in today’s rapidly changing marketplaces.

There are a significant number of reasons why it’s so challenging to effectively bring products to market.  Some are external, such as changing market conditions or shifting customer needs. However, many problems result from internal challenges such as overstretched contributors, the wrong mix of skills, poorly understood processes, and misalignment between the core team members in the value creation process.

Professions such as business analysis and project management have boundaries and roles that are well understood. Both have their bodies of knowledge, process groups, and foundational knowledge areas.  In contrast and ironically, the product management profession spans 70 years but has yet to fully codify its body of knowledge. The resulting lack of clarity on the responsibilities and boundaries of a product manager often contributes to many of the internal inefficiencies and missed opportunities we see within today’s organizations.

There is often tremendous internal confusion regarding the role, span, and scope of a product manager.  Ambiguity in the responsibilities of this role leads to dissonance and tension as the key stakeholders in the value creation process – project managers, business analysts, and lead engineers – struggle to understand what to expect from product management. Given the profession’s historical fragmentation and lack of a solidified standard, where does one look? What are the boundaries of the role and how can we work together more effectively?

Product managers are responsible for creating and sustaining value throughout the entire life cycle of a product. The focus on creating and sustaining value is what makes product management unique.

The product management life cycle is composed of both stages and phases that chart the course of a product from its conception, the Conception phase, to its ultimate withdrawal in the Retirement phase. The stages and phases are concurrent activities. This framework is universal; it applies equally well to products or services.

Now that we’ve defined the role of a product manager and illustrated the life cycle, we can drill down a bit further and examine why business analysts and product managers are perfect partners.

Stay tuned for part two.

Greg Geracie is a recognized thought leader in the field of product management and the President of Actuation Consulting, a global provider of product management consulting, training, and advisory services to some of the world’s most well-known organizations. Greg is also the author of the global best seller Take Charge Product Management. He is also an adjunct professor at DePaul University’s College of Computing and Digital Media where he teaches graduate and undergraduate courses on high-tech and digital product management. 

The post Product Management and Business Analysis – Perfect Partners appeared first on Actuation Consulting.