Technical Product Management according to Open Product Management Workflow

The Product Management book for technical Product Managers and Product Owners that explains tasks and roles as well as prioritization of requirements

Frank Lemser

• Publisher: Books on Demand
• Year: 2019
• Print ISBN:
  9783749452170
• Edition: 2
• eBook ISBN:
  9783749427338
• Topic: Business
• Subtopic: Business General
• Index: Business

The book »Technical Product Management« is the continuation of the series Product Management according to Open Product Management Workflow and is aimed at Technical Product Managers and Product Owners. Note: the tools and templates, which are mentioned in the book, are deliberately not included, but will be issued in the trainings, as their application needs to be explained and exercised under guidance in practical examples.Additionally, you can also download the book »Technical Product Management« for free in PDF format on the proProduktmanagement website.You will learn how to use the information gained from the book »Strategic Product Management« in product development.First of all the book »Technical Product Management« deals with the set up of the technical product team. You will learn which different roles exist and who takes which tasks in this technical product team and why.To prioritize the requirements for product development, based on market facts, you will learn how to develop a rating scheme, taking into account time-dependent sales, long-term strategies and economic aspects. Read about the advantages of user persona in communication in product development and learn how to set up user persona as well as clear requirements for product development.You will learn more about the exemplary product »SelfBackup«, which was already introduced and explained in the book »Strategic Product Management«.As mentioned above you can download the book »Technical Product Management« on the proProduktmanagement website for free and read about preprototyping and numerous other topics relating to product development from a Product Management perspective.

REQUEST RATING

Please note: For the next chapter, we require that you have previously read “Strategic Product Management” according to Open Product Management Workflow ^TM, as this chapter builds on this knowledge.

Once in the cycle of each product, Product Managers look at the huge quantities of requirements and already know how exhausting the days and weeks to come will be.

Huge Excel lists with 2,000 things which are required for the product. Customers, Sales, Management, Engineering, Technology and Sales Partners - a certain functionality is important for the next product for every single one of them.

But who is right? Which things are most important? How can you comply with each one and what reason can Product Management give if a functionality is not developed? Do the functionalities all fit together and do the customers really need all that?

Product Managers have a critical look at these and other questions when it comes to assessing and deciding the list of requirements of what is to be developed by the Engineers. Teams consisting of Product Management, Project Managers, Product Architects and other colleagues work for days and weeks in order to make this decision.

It should be clear to everyone at this point that a lot of money is invested here, in addition to time, because the decision-makers are often well-paid employees in the company.

However, experience shows that the products created at the end are often not 100% appropriate for the market, or are only appropriate for a small group of customers and the actual target group has only partially been reached.

Practical example:

Marcus, a Product Manager at an internationally-active company, told us that he needs 4-6 weeks for the requirements rating of his product and must also hold numerous meetings with the heads of the engineering department Nevertheless, Marcus is more and more uncertain whether or not the right features are being put into his product.

In another organisation, we saw for ourselves how the Senior Management took part in a meeting about the requirements rating for a week and played an active role. The entire decision-making process took more than 4 weeks, since ultimately other departments wanted to cast their vote.

In these companies, there are usually several causes for such a time- and money-consuming requirements ratings.

1. Product Management themselves have conducted no interviews and have little knowledge of the market
2. There is no procedure which brings all requests from a variety of sources into one uniform format in order to allow an assessment
3. A scheme and the criteria for a market-oriented assessment of the requirements are missing

You have already learned in the "Strategic Product Management” section what to do in order to change the first point.

You can solve the second point by bringing together all of the requirements into a uniform and similar format.

To do this, you will receive Document T2 "Product Enquiry" from us. This Document T2 is structured similarly to our Interview Protocol. Additionally, the question has to be answered as to who takes on the costs for the development. This can be a customer, a technology partner or the company if a problem is mentioned frequently and therefore one of the market-relevant target groups lies behind it.

A solution for point three - a scheme and the criteria for a market-oriented assessment of the requirements - is covered in the following section.

In practice, a format that is frequently used to pass a requirement to the Engineers is the so-called story card or the requirements map (Document T3). We also see product concept catalogues, functional specifications or requirements documents again and again.

For the rest of the course we will use the story card or requirements map - Document T3. You can easily include this form in your documents. Our Document T4 offers another detailed and classic form of a requirements description.

In addition, we’ve provided a new and more modern form (Document T3), since it is becoming more and more popular in practice.

In order to convey the process clearly, let’s use our example product SelfBackup for our Claudia Persona.

So, we start with a typical requirement which we frequently encounter in a similar form in practice.

If you pass on this requirement in such a way, then your colleagues from the product team can’t really do much with it as there is a lack of information for the Concept Developer/Designer, for example. In addition, it is also a very unspecific format. What does "optimal" or "simply” mean?

As you have already learned, we have to personalise the requirement.

Our requirement is made up exactly of the already identified parts - problem, persona and scenario.

We include these in our map:

As we have already mentioned, such maps are also called story cards in practice, because a short story is told using the following format:

Persona has the problem in the Use Scenario with a frequency.

The values are inserted for persona, problem, use scenario and frequency which were determined in the interview protocols or disclosed in the business proposals.

First, let’s start with the persona and the problem:

“Claudia would like to run backups. Because she doesn’t understand the setup, she can’t do it.”

Then we add the use scenario in:

“Claudia needs a guided selection of the folders that she wants to back up.”

Now we answer the question, “How often does Claudia have the problem?" and record the value for the frequency:

“She needs to make this selection once during the setup of the backup system.”

A descriptive, meaningful title must be found at the end that allows you to surmise what the story is about when reading it.

Tip: In practice, a question used as the title has proved successful, because the question implies exactly what the content of the story is.

Our map now looks like this:

You may have wondered why we use the frequency to create our map. This is, for example, required by colleagues who create the concept and/or the design. It plays a role in the use of products of which functions are to be used how.

Examples:

Have a look at your email programme:

All the things you have to do more frequently, such as:

• New email
• Delete
• Reply

You can get to directly with a click of the mouse.

Similarly, in cars with radios with built-in sat navs, you find frequentl...

Table of contents

• Notes
• Table of Contents
• Preface
• Introduction
• Product Management in the organisation
• The Product Management Dilemma or how Product Management should build the future with a hammer and chisel
• Use free software as Product Manager
• The Technical Product Team, tasks and roles
• User Persona - Document T1
• Use Scenario
• Request Rating
• Definition of Work Packages (Work Package definition)
• Time and Costs
• Prototype and Pretotype
• Review meetings
• Approval
• Open Product Management Workflow TM as software
• Product Management Dashboard® - Produktmanagement Software Plugin for JIRA®
• Further support for you
• Open Product Management Workflow TM Licence
• Copyright