How to begin? Began why?
My product journey was a bit long…
I think that’s the way it is: all journey is long when applied to software as a product
Product management is to think about the supply chain and a product manager should have a global vision of everything that surrounds him.
Don’t assume that vision is universal and always be aware to look for other ways to connect more deeply with the challenges and turn those into opportunities. It’s more about empathy and patience than other stuff.
In my product management journey, I’ve had the opportunity to apply too many methodologies and frameworks. My favorites are:
They aren’t a silver bullet but they brought me great results. All of them proved to have usability as oblique language and to require less technical skills, both good things to maximize project expectations of success and as consequence to allow me, as a product manager, to see a clear picture of what I was doing.
Combine, Improvise and Repeat to improve a product.
Product management is part of a supply chain, nevertheless, a product manager has to be aware of the whole product journey.
“A great product manager has the brain of an engineer, the heart of a designer, and the speech of a diplomat.” — Deep Nishar, Vice President of Product at LinkedIn
I believe that is the best definition of the PM mind set.
The product life-cycle
A product life-cycle journey has four stages. In fact, we can compare it to storytelling with rises and falls.
If everything goes as expected I will lead you to a path of profit before the journey ends.
In this case, the product has four stages:
- Introduction — Introduction — when the product is introduced and struggles to have brand recognition.
- Growth — Growth — advertising and word of mouth helps the product to increase sales. As sales grow, more entrepreneurs are willing to stock the product which helps it to grow even further.
- Maturity — Maturity — When the product reaches a peak at market penetration.
- Decline — the product gets eclipsed by new products.
Between maturity and decline, we had extend the product life with upgrades add new features and services.
Many companies want to see the product ecosystem with those new features inside it. That will help in the previously mentioned product/life-cycle extension.
Began why?
Have you heard about the napkin sketch story?
A brilliant new product idea is first sketched out on a napkin and the idea was born.
This initially written definition of what the product will be is commonly called: Product Requirements Document (PRD).
The PRD has many sub-documents and artifacts that refine the product, such as the Market Requirements Document(MRD) or the Engineering Requirements Document (ERD).
The main difference is that the PRD is where things come together for those who are involved. It’s a full-stack document.
This model provides a platform base for user story specifications.
Be in mind that PRD isn’t written once and never touched again like a napkin sketch. It should have continuous reviews and updates to be refined as the project and product evolves.
It has to be the start point for many groups within the development process and it allows the team to identify design challenges earlier. It also shows areas that might require early mock-up testing helping to identify test plan frameworks and to serve inputs for marketing material (if wasn’t published), besides to facilitate to reduce cost assessment challenges.
It is a road map for development, not a solution
Beyond all said, it also helps to identify the product gaps like low-performance functionalities or poor environment distribution or even wrong types of market users.
Furthermore, it will list what are the specifications that new products have to meet (As a checklist of all challenges, not a recipe. Be clear about that).
And that is what the development team will have to: solve challenges.
A well-written PRD should help the whole team to be more efficient with the constraints they have. Keeping this in mind can make the difference between getting to market or not.
Initial drafts of your PRD do not have to be perfect or complete in the early stages. Features that are not well defined can be out at the first glance.
The PRD should be, at the beginning, a simple guide to orient you, just like the napkin sketch. Specifications eventually will get refined and some initial goals may be exceeded, deprecated and updated.
To end with, but not less important, the product manager of this journey should be a full-stack of the product domain or an expert of its supply chain and should know there are eight useful domains to be aware of:
I truly hope that all said I could give you my thoughts about the PM career and how I think it should be done.
The post stays but soon enough I’ll publish something about “Essential open source tools for product managers”.
Thank you all for reading and helping me to transform this road in a very interesting journey.
