13 Pointers if you are in a Product Role
As I often find myself in the intersection of tech & product for fast growing startups that are trying to find product market fit, these pointers have helped me to work effectively to figure out next steps for the product. #productnotes
The “Product’ role is relatively new and there are no clear definitions for it as it often varies across companies. Interestingly it started off from a marketing role and then has moved to a place where the role often sites between
different stakeholders of a company be it tech (UX/UI), sales, business, customer support/user research including marketing.
(1) To have a successful product, the idea is to keep asking *WHY *keeping
the end user in mind. If the repeated whys are not answered clearly, the
underlying assumptions need to be revisited.
(2) Software engineers build and fix bugs in the product and need their mind
time utilized effectively for just that. The role of product is keeping the line
from end users to engineers short, effective and two way, getting all
distractions out of the way.
(3) Building a good product is often full of distractions, more prone to
failure than you expect and can get easily complex. Keep things as simple as
possible (KISS), and prioritize ruthlessly.
(5) To reduce complexity, a product is often dividied into smaller products/features like by
- Platform: iOS vs Android vs Web
- Feature: Recommendations on Netflix, Search on Spotify, Messenger on FB, Moments on Twitter.
(6) Define your Metrics
KPI or Key Performance Indicators define if the product is going in the
right direction. KPIs bring teams together and its important to define them
well. Common ones are
MAU/DAU = Monthly active users, daily active users.
MRR = Monthly recurring revenue.
(7) You don’t need to be the IDEA person to figure out how to solve all
product problems. As long as every major decision comes from a deep desire to
get closer to the truth to find product market fit, you are avoiding major pit
Where do ideas come from? Employees, Metrics, Users
(8) Technical Knowledge
- AB Testing (Optimizely)
- Core principles for UI/UX design to not reinvent wheels.
- Analytics (Google, Kissmetrics) and how to track actions.
- Prototyping using Proto/Balsamiq
(9) Product lifecycle
Be aware of which stage a product or feature is in.
- Conception of Feature after Ideation/Brainstorming
- Project Planning
- Developing Software
- Iterate (Test feedback)
- Iterate + Steady state (OR) Fail
(10) How do we develop the product?
Minimum viable product (MVP), Lean Startup by Eric Ries talk enough about to keep product development effective.
From a software point of view, development is “Agile”, and there are two schools of thought.
Tickets created are units of work assigned to a developer.
Sprint. Generally two weeks.
Sprint planning moves tickets from product to sprint backlog.
Daily <15m stand up meetings with (Now, Blockers, Next)
Not as strict as Scrum, more “relaxed”. Harder to “estimate” work.
Kanban Board. Has only three columns. TODO, IN PROGRESS, DONE.
No sprints. Only “product” backlog, which is endless.
No specific meeting types.
Only a certain number of tickets that are in progress.
(11) Set up an effective COMMUNICATION architecture.
People fuck up all the time, so keep the atmosphere positive, less blame games,
give credit when its due and keep customer satisfaction as your light at the end
of the tunnel. This can happen irrespective of what personality type you fit
With communication, focus on the what (given whys are answered) over the hows.
- 1–1 meetings. How are things going?
- *Retrospectives from sprints. *What have we done the last two weeks? How can we
do better the next two weeks?
(12) Common Cognitive Biases
- Halo and Horns effect. Causes you to allow one reason/one advantage,
either good (halo) or bad (horns), to overshadow other reasons. Eg: Good looking
people thought to be intelligent.
- Availability bias. We tend to remember frequent & recent events and use that
for reasoning even though they might not be supportive (enough)
- Sunk Cost Fallacy. Classic. We tend to rationalize and put more resources to
a project that is failing hoping to see the tables turn. Often why pivot
decisions take longer and feel hard to make.
- Boredom syndrome. Most (ambitious) humans have the tendency to need to act,
even when their actions are not needed. We also tend to offer solutions even
when we do not enough knowledge to solve the problem.
- Influence of stress. Biases become more prominent when stressed. Hasty
(13) Conduct User interviews
Often under worked on, but talking to end users defines where the product needs
- Ask for feedback often and go after different profiles of end users.
- Have a clear list of questions to ask them and keep this open with WHAT and HOW questions. Informal however.
- Don’t reveal what you are working on. Its important that they trip on it and
this is possible because its a “problem” they have. This is the AHA moment you
have to lead them into.
Each of the above pointers may or may not work you since each product/team is
What have I missed?