Product management is just management. However; it is just different enough that it gets it’s own category. It does so because it is complex in the following ways:

1. software requires software engineers, a very expensive and hard-to-hire resource.
2. software is a complicated thing with many dependencies & even more moving parts.
3. software & the changes you make to it will simultaneously impact often millions of users.

Good product is built on some bedrock principles that I’ve written about before that may be worth a quick review

• Strategy: First Principles
• 7 Powers
• SDLC

With that primer, let’s explore!

The Software Development Life Cycle is a good framework to organize with. It really kicks in when you are confident you have Product Market Fit (it solves a real problem enough that people will pay for it).

The SDLC consists of 4 steps (plus a bonus one I’ll throw in): Plan, Do, Test, Deploy, Document.

1- PLAN

Super plan

Think big before you think small. You’ll need to define the general direction and big jobs that you want your software to accomplish first. Whether you call these “epics” “big rocks” or you end up changing them – you’ll start here. An example might be: “We want to change the newsfeed to bring people out of echo chambers on our social media platform this year.”

Sift Backlog

Your backlog is your wish list of things you’d like to add to your product. It will always be bigger than you’ll be able to accomplish. You’ll need to select carefully and strategically to win. Use criteria like:

• customer feedback: have you heard complaints or suggestions that suggest you should choose one wishlist item over another?
• testing: can you rapid prototype a feature and test small to prioritize one item over others?
• critical thinking: don’t underestimate rigorous thinking. You will make mistakes in the process of managing a product – you must however minimize the ones that come from lazy thinking. Some important examples are: not realizing there was a dependency that you didn’t anticipate, does it really map to solving a problem or is it just something we think is cool?

Story

You’ve selected your priorities, now you’ve got to make them ready to delegate. Constructing them into story format does two things, 1) it ensures that you are driving toward helping users 2) ensures that engineers know the exact purpose of what they will code, allowing them to focus on code. A good framework is:

AS A __social media user__

I WANT TO __remember the things I clicked like on__

SO THAT __I can easily find them again__

Size ’em

You need to decide how long these stories will take to build, so you’ll involve your engineers to make some sense of it. Software is notoriously difficult to predict so it is common to use rough guesses. Since software engineers are abnormally intelligent, you’ll often see a fibonacci sequence to estimate. A story that is graded a 1 is easy, a 3 is pretty easy, 5 normal, 8 tough, 13 tougher, etc.

Wait – why not use hours? Generally it is too easy for managers to start managing if you use hours and it doesn’t translate well into managing creative and unpredictable work that writing code entails. It is better to abstract it a bit as a constant reminder.

Sprint

A sprint is a defined period of time (usually a few weeks) that you batch your sized stories into. You’ll begin the sprint with a kickoff and you’ve completed the planning process and will move to the next stage.

2- DO

Software creation

This is magic right here. Engineers start coding the stories. All of your effort and planning as a product manager is to let the artists do their work as focused and optimal as you can make it.

Standups

You’ll meet daily to get a status on how things are going and ensure there is help available where needed and that nothing is holding back progress. These should be short and sweet: what did you do? what will you do next? are you stuck?

Send

When code is complete they’ll request a code review to make sure a peer or leader takes a look at their work and gives feedback. Ultimately that code will be committed to the version of the software you are working on for the sprint. (see Dev Ops article for more on versioning)

Squashing bugs

A bug is an unexpected problem in the software that doesn’t go through the entire planning and backlog selection process. These require immediate action and so will be part of the regular course of work.

3- TEST

Setup Testing

Does the code work? Can you automate the testing of the code so you optimize engineers doing what they do best? You will test code in two ways: 1) does it work on it’s own? 2) does it work with the other code that it is part of. The more modular you can make this work the better. (Read more about modularity in the Dev Ops article)

4- DEPLOY

Send code to production

You’ll ultimately send your work to the “production” environment or live to users. It is wise to do this in rounds so everything doesn’t go live at once (just in case there is some problem that survived testing). A note you don’t always release new versions at the end of a sprint – it could be more or less frequent. Many modern development shops are on a continuous release that has automated and regular pushes to production happening many times per day.

Share progress

You’ll typically end a sprint by sharing your finished work with your own & possibly wider teams and doing some sort of retrospective to reflect on the process & approach for improvements you could make for the next sprint.

5- DOCUMENT

Synchronize

As a bonus to the typical 4 steps of the SDLC, you’ll also need to ensure that you are synchronizing all of your documents to correspond with the new build you’ve accomplished in a sprint. Release notes describing those changes to users are common as well as updating any marketing materials associated with the product.

So what?

That’s it! While the labels and details may vary in your situation these are the core principles that make this type of management “Product Management”.

As a builder you want to make sure you are executing on the basics like these so you keep progressing to bigger and better goals – happy building!