Context

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 sits between different stakeholders of a company be it tech (UX/UI), sales, business, customer support/user research including marketing.

Lets go

(1) You are responsible for the ultimate success of the product. 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. Often the last set of whys answered lead to a fundamental human need.

(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. Its more facilitating & leading and less managing.

(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.

(4) 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.

(5) 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.

(6) 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 falls.

Where do ideas come from? Employees, Metrics, Users

(7) 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

(8) 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)
• Launch
• Iterate + Steady state (OR) Fail

(9) 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.

• SCRUM

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)

• KANBAN

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.

(10) 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 into.

With communication, focus on the what (given whys are answered) over the hows.

What works

1. 1–1 meetings. How are things going? What are you concerned about?
2. Retrospectives from sprints. What have we done the last two weeks? How can we do better the next two weeks?

(11) Common Cognitive Biases

1. 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.
2. Availability bias. We tend to remember frequent & recent events and use that for reasoning even though they might not be supportive (enough)
3. 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. “We have come this far…”
4. 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.
5. Influence of stress. Biases become more prominent when stressed. Hasty decisions.
6. Mood affiliation: People choose a mood or attitude, and then find the disparate views which match to that mood and, to themselves, justifying those views by the mood.

(12) Conduct User interviews

Often under worked on, but talking to end users defines where the product needs to go.

• 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 different.

What have I missed? Let me know in the comments.

Thanks to  Ricardo Vice Santos & Ian Robbins for their tips here.