PRODUCT MANAGEMENT

Product management is something I have been very interested in for a while. Throughout my journey, I have made many mistakes and learned so much. Honestly, I think product management could be done differently. Below are my thoughts.

My Product Management Style

Brief Intro to Product Management and the Problem I See

The definition of product management (PM) is planning, developing, launching, and managing a product or service. It includes the entire lifecycle of a product, from ideation to development to go-to-market. To most of us, that is obvious but there are some projects I have been on where the focus was only on revenue and those projects have all failed eventually. PM should have a complete focus on user value which means building the best product experience.

The Problem Continued

There are many businesses out there that only focus on profit and only see users and customers as a necessary medium to get it. In my opinion, companies must obsess over the user experience and figure out the money later. It is actually the businesses that don’t do this that end up limiting their standing and don’t survive a long time.

There are even companies we are interacting with every day that used to obsess over the user experience in the beginning and changed their focus once they became large. They are either slowly declining in users and adoption or have died (e.g. Blackberry, Toys R Us, Kodak, Harley Davidson, and even Netflix in my opinion, etc.).

My Interpretation of a Solution

Product management, in my view, should a sole focus on bringing value immediately. This is much easier said than done but there is a way to do it that many businesses are already taking advantage of. We do this by combining three principles that root in design, entrepreneurship, and software engineering: Design Thinking + Lean Startup + Agile (shown below)

In more detail, the theme is to build in small chunks, release to a subset of users or a beta group, collect feedback on all aspects of the product, adjust the product accordingly, and repeat. Let’s break that down

We build small so we can get feedback asap and when negative feedback inevitably comes, it’ll be so much easier to correct as opposed to fixing a larger release
We release to a subset of users so that we can fail and not affect as many people. Failing is not something to avoid. It is a tool that can speed up PMF. We don’t waste time pretending something works when it doesn’t
We collect feedback on all aspects of the product because we have a conviction to validate the value the product is giving. The feedback must be honest and thorough.
We adjust to make sure we don’t procrastinate on the issues users are having with the product. Since we are building in small chunks, we can maintain this and release changes quicker
We repeat to ensure the product is always providing value and building ourselves a trusting rapport with the users

Again, Easier Said Than Done. How Can This Be Accomplished

This is why I use an agile methodology no matter what project I am working on. Check out my article on why I use agile and Scrum. Here is how we apply it to product development.

The System

A product team should use this system: business vision, product, feedback, and team cohesion.

In an agile product team, there are four roles; product owner, development team, stakeholders, and scrum master. Each role has complete ownership of a part of the system

Product owner (PO) is responsible for the business vision
The development team (Dev) is responsible for the product
Stakeholders are responsible for the feedback
Scrum Master (SM) is responsible for team cohesion

With the responsibilities divided, the entire team can focus on their part and not worry about the others. This leads to fast and smoother teams and product development.

How to Build and Ship Smaller Chunks

In order to do this, we must define scrum a bit more. Now we know the roles, how do we functionally use all the roles. Scrum is a series of meetings that we repeated in sprints (1-2 week timeframes).

In that time, there are four kinds of meetings (i.e. sprint planning, daily scrums, sprint review, and sprint retrospective)

To start a scrum process, we take the business vision and define a definition of done (DoD). This definition has to be discussed and agreed upon by everyone.
Then we list all the possible tasks needed to complete the product. This list is called the Product Backlog.
Once the Product Backlog is filled, the team then meets for a sprint planning meeting. This meeting should include PO, Dev, and SM but does not need stakeholders. During this meeting, we look at the Product Backlog and select the tasks we are looking to complete in the upcoming sprint.
By working in sprints, we can build and ship faster.
After the sprint planning, we do daily scrums (also called standups) to provide a quick update to the team. Daily scrums are every day until the end of the sprint.
Once at the end of a sprint, we meet with everyone on the team including stakeholders, and do the sprint review. This is where we review the work completed in the sprint by
- demoing what was created for the stakeholders
- collect their feedback and see if it meets DoD
- and see if we hit our sprint goal, discussed during the sprint planning.
Lastly, the PO, Dev, and SM meet for a sprint retrospective which is meeting to discuss team cohesion (e.g. conflict resolution, team dynamics, etc.)

Having all these meetings every one to two weeks may seem like a lot of work and time in meetings but in actuality it does not. Every meeting has a set time box with the sprint retrospective taking the longest which is one to one and a half hours max and that is only once at the end of the sprint.

To Recap

Business leaders have traditionally built products to optimize revenue and profit. In reality, their view of using users to be the necessary medium for making money as opposed to a focus on user and product value/experience, their business ends up failing and making less money over time. To not fall into this trap, product teams must build and release in small chunks, collect feedback, and adjust to stay relevant. In order to do this, they must be agile. Let’s make sure we are creating product teams that are healthy and efficient and actually care about the people that are using their products.

GET IN TOUCH

Using scrum to build products efficiently WITHOUT compromising team health is a passion of mine. I would love to talk about scrum or any of my projects with you :)

515 E Grant Street

Phoenix, AZ 85004

me@aritrom.com