Product Management Playbook — Part 4/6 — Development

The question we ask in this segment is “How do we build a viable product after ruthless prioritization that solves user problems?”

In my series “Product Management Playbook — 6 Part Series”, I focus on how product managers can build awesome products that users will actually love and use. In the First Part, we understood the users and their problems. In the Second Part, we looked at how do we combine all the research and define where the problem’s exist. In the Third Part, we looked at how can we ideate to find an appropriate solution for the needs and problems we defined. In this Fourth Part, we will look at how do we prioritize and actually build a product.

The goal of this phase is to prioritize and build the best possible solution to solve user’s problems or address the user’s needs.

After the ideation phase, you might have come up with multiple ideas on how to solve user problems and provide users with what they need. Obviously, due to limited economic resources, we cannot build everything you have dreamed of, simultaneously. So, we have to prioritize what to build first.

Prioritization

Prioritization is the most hardest part of life. No one is ever sure of what should go first. There are multiple prioritization frameworks available across the internet. Below is an article on Folding Burritos, which discusses various prioritization frameworks.

20 Product Prioritization Techniques: A Map and Guided Tour

My Prioritization Framework

I follow a simple but very effective prioritization framework which always worked for me.

1. Plot all the features/tasks as shown in the above plot
2. Apply constraints — budget, timelines and other dependencies
3. Finalize on the features/tasks with largest ROI within constraints

Design and Develop

Now that we have identified, defined, ideated and prioritized the product features, we need to actually build it. What we are actually doing here is we are testing the assumptions we made about the ideas which we think will solve the user’s problems.

Inputs to Engineering Team

Here, we will express the requirements in such a way that the people who actually build the product understand it correctly. There are different types of requirements that need to be documented:

1. Business Requirements: These requirements outline the purpose of the product. For example, “Users need to have access to products and services within the application to prevent any possible revenue leakages because of the approximation of unit values of products and services”.
2. User Requirements: These requirements outline exactly what tasks, user can do within the product. These can be expressed as use cases and user stories. For example, As a <User>, I want to <Perform certain action> so that I can <Achieve some benefit>
3. Functional Requirements: These requirements outline the behavior of the expected product. These are usually expressed as inputs into the product, the outputs of the product, or description of the behavior itself. One way of expressing functional requirements is through ‘information flow diagram’ or ‘data flow diagram’ as they depict the way information or data flows through the system. Data flow diagram is shown in the image below.
4. Non-Functional Requirements: These requirements outline how well the product should perform. These requirements are also called as quality requirements. The non-functional requirements can be divided as follows — External Requirements (regulatory requirements and ethical requirements), Organizational Requirements (environment requirements, development requirements, operations requirements, …), Product Requirements (usability, reliability, performance, space, security, …)
5. System Requirements: These requirements outline how the product interacts with other entities within a larger system. For instance, the product might need data from another product which needs an integration including protocol and content format. External system interfaces can be represented within data flow diagrams that show all the components of the product including external entities. Data flow diagram is shown in the image below.

Data Flow Diagram. Credits: Software Product Management Specialization — Coursera

Inputs to Design Team

Here, we will express the requirements in such a way that the people who actually design the product understand it correctly. That can be done in two ways:

1. Wireframes: Wireframes, also known as mock-ups, are the most popular input to designers. These are nothing but a basic and very crude visual representation of the product. Wireframes are known to be very simple, but very effective in outlining the basic functionality of the product. Wireframes do not use colors or images. Instead, wireframes may suggest things like where buttons, text fields, and images are placed. Wireframes are usually developed quickly after an initial discussion with the client regarding requirements and presented thereafter. It also ensures that both the client and development team are working towards the same vision.
2. Storyboards: Another technique used to help in forming requirements is storyboards. Storyboards are sequential, visual representations of an interaction with the software product. Storyboard combines wireframes and basic flow from use cases in order to show how the end-user interacts with the user interface of the product in detail. It also shows all the sequences of user interaction with the product, and the outcomes of those interactions. Each state of the product during interaction is illustrated with a wireframe. The user interface element needed to get to the next state is also illustrated. Transitions between states are generally depicted with an arrowed line. Wireframes & storyboard is shown in the image below.

Wireframes & Storyboard Diagram. Credits: Software Product Management Specialization — Coursera

Managing Risks and Quality

Once the inputs are provided for the design and engineering teams, it is also the job of the product manager to manage both risks and quality. Risk is anything that might hinder you from achieving your product goals. Risk cannot be eliminated, it can only be managed or mitigated. Enlist and manage your risks using a risk management framework, including Risk name, Description, Occurrence probability, Impact and Status.

The product manager should be the yardstick for quality. Product managers should create an environment where quality is expected of everything. Software product quality can be expressed in terms of Effectiveness (users achieving specified goals), Efficiency (users achieving specified goals with minimum resources), Satisfaction (degree to which users are satisfied when product is used in a specified context of use).

So, this is how a product manager prioritizes his next tasks from the large product backlog, express the detailed requirements for designers and engineers to help them build the product according to his vision.

“A great product manager has the brain of an engineer, the heart of a designer, and the speech of a diplomat.” — Deep Nishar, SoftBank Group International

What am I missing here? Let me know in the comments, and don’t forget to share your ideas too!

Enjoyed what you read? Hit the CLAP below and share it, so that others can read it too.