Anything as a Product
Becoming a Product Manager has fundamentally rewired my brain. I think of everything as a product, really.
When I say, ‘everything’, I’m talking about the entire gamut — children’s toys, medical devices, teacher training facilities, pharmacy counters. All these can also be looked at as a product. No, I’m not just talking about the tech products which you see listed on ProductHunt.
What’s so interesting about calling anything a product?
Thinking of a project as a project, or as a product are two different things.
They CANNOT be used interchangeably.
If you’ve been running various projects and would like to incorporate product thinking into your projects, here are a couple of things you could get started with:
Treat products as living, breathing creatures.
For a project, there is a fixed timeline and a fixed end goal in mind. Once the goal is met and the timelines are met, the project is COMPLETE. They are time constrained efforts which are supposed to be defined upfront. Fixed scope. Fixed time. Fixed cost.
Products, on the other hand are evolving creatures. They evolve in accordance to the growing needs of the company as well as the users’ needs. By this nature, they have to be constantly learning and adapting.
Remaining static (project-based) in a dynamic world, comes with it’s share of dangers. Projects don’t welcome change. Whereas, change and evolution are natural in products.
Shreyas Doshi, a product expert talks about the various differences when it comes to project and product thinking approaches.
Become a philosopher-in-residence.
To accommodate change, The Product thinker has to take in inputs from customers on a frequent basis and tries to balance and define requirements based on the company’s needs. Feature requests come from all corners.
When there are various moving pieces in line, the product manager has to prioritise the features based on various factors such as (a) cost, (b) complexity, (c) risk, (d) customer impact, (e) projected sales impact, (f) documentation etc..
The product person within an organisation plays multiple hats. One of them being that of a philosopher-in-residence constantly asking these questions and helping drive action and alignment across the board. You are asked to be critical, but also creative. Customer facing, but also business facing. It’s a one big balancing game.
The main question which the product manager is trying to drive is not in managing the laundry list of feature requests. It’s about constantly asking WHY. What are the evidences?
Why is it important?
What are our goals?
What else could happen?
How will it differentiate?
Why? Why? Why?
Rewrite the feature requests as user stories.
Features become the means to end and not an end in themselves. **When you make it about the customer, nobody can disagree unless they have a very strong reason.
- Boost creativity by providing clarity on the problems being solved. When we focus on solving a problem rather than building a feature, it gives us much more room to maneuver.
The most popular template for structuring a user story is the following sentence:
As a _, I want _ so that I _
The three variables can be understood as follows:
User X— signifies the user persona that is requesting the functionality.
Functionality Y — signifies the behaviour/functionality the user needs.
Goal Z — Signifies the need the user wants to get fulfilled through the specific functionality.
- As a passenger, I want to know the estimated arrival time for a cab so that I have an idea of how long do I need to wait.
- As a passenger, I want to know the total fare so that I know how much the trip is going to cost me.
- As a passenger, I want to be able to call the driver so that I can coordinate with them if required.