Thoughts on Product Management

Observe, Prioritize, Prototype, Spec, Price, Build, Test, Launch, Observe…

If you work or live in the product world you’re likely familiar with these phases that are key to successful product development.

I’ve become interested in product management several years ago when I was planning on developing an idea I had in mind. It was first introduced to me by someone I met at a tech conference in Vermont through the word “MVP” which in tech world didn’t mean what I thought it meant. The person explained to me how apps were being developed and how I needed to identify the most essential version of it and work on developing that first. That sounds easy enough if you already have a product in place, but it may not be so clear when you are starting from the ground floor.

Observe.

Always be listening.

You may have different sets of audiences. In my world I have my end users first, that are divided into two subcategories, Individual and HR Director, and then secondly, I have my business users and admins. Being in a constant listening mode allows me to capture input and shape the development roadmaps from these users. The ideas and feedback comes from many channels and different forms like an email, a verbal communication, slack, webform, etc. Once captured the feedback goes through a visualization process. I use mainly a UI prototyping software for it but I use other methods and tools as well, like post it notes, a whiteboard, Miro, etc. to solidify the idea and bring to a point so I can easily share with t teams.

Prioritize-

Feedback and ideas are a plenty and they are dear to each person who’ve provided the feedback to you so this is the part it gets tricky to navigate when you prioritize all the feedback for your next round of development now t

So how do you prioritize?

It’s actually simple, first group ideas in levels of relevancy and depency. Then assign the impact you expect to get from each of the items and add up the impact score. Next, plan out how you will measure the success from each implementation. This part often goes unnoticed during the development cycle. Many implementation’s impact are never measured. For each of the items I implement I include the success measurement metrics at the beginning and the timeline to measure it. This helps me to get back to stakeholders and close the feedback loop on how their idea has performed.

Prototype

This is an important step. People often verbalize their ideas to you in a way that it leaves too much room for interpretation and this sometimes results in a disconnect between the originally communicated idea and the resulted implementation.

This is where a prototype comes into help. most of the time a low fidelity prototype, i.e. post it notes or white board or even a few screen captures manipulated to desired outcome is enough to have the stakeholders agree to a solution . And when this is not enough there are ways to create high fidelity prototypes with close to production quality renderings and functionality to get the idea across. For me, I live mostly on the low fidelity side of the spectrum about 90% of the time.

Spec

When prototypes are agreed on the next step is to spec the work. A detailed documentation including diagrams, prototypes, written explanation of the functionality, the UI and UX description, scenarios to test against should be all included here. This should allow the developers to get the full picture of the problem and the business goal.

Price

In my work I collaborate with both internal and external development teams, so sometimes the price is measured in terms of time spent on a project with our internal teams. So once we have everything we want specced out the development teams spend sometime to review our requirements. In most cases it’s expected from development teams to come back with questions and recommendations. We often tweak the requirements documentation at this stage one more round. Then receive the pricing and a timeline to complete the project, which in turn goes through an approval and procurement process before it’s initiated.

Build & Test

The build phase is usually the bit so fun part of the project in my opinion. I usually start thinking about the next development phase and features at this point. The testing is a crucial part of the whole cycle. We identify teams and individuals to run tests on features and return feedback back to developers before the feature is released and launched to public.

Observe

You guessed it. Once everything’s in place we spend the next several weeks, or sometimes months, to observe customer behavior and try to learn from them. Again, we use this data to gauge the success of our implementation.

Conclusion

As you’ve gathered this is a cycle of processes chained together. And, when we are finished with one project we start another, and in reality there are usually several projects going on at the same time and in different stages of the process. For example I usually have more on the Observe and Spec buckets than any other.

You may also ask if one process is more important than the other? I going to measure importance in terms of time. For instance I’d like to spend more time in the Observe phase to gather as many point of views as possible, this allows me to create a fuller feature. I also spend a great deal amount time in the Test phase. This includes creating test cases, allocating test teams, performing tests, receiving feedback, and resolving the bugs as a result.

Do we skip any of these steps at any point in time? While some of these steps may take less time than others they are all essential parts to the whole so skipping or rearranging is not going to help the desired outcome and I’d definitely not recommend it.

Finally, I enjoy product ownership and management roles where I work. It’s an area that’s developed a great deal in the past decade or so with frameworks and tools to help manage these processes easier than before. And it’s worth noting that whether you are a product manager, product owner, or a project manager, the key ingredients are, in essence, people and resource management. Without the right people skills it’s impossible to move any piece of the project forward or at least in an efficient manner.

I hope you enjoyed reading through this blog post and would love to hear from you if there is anything you’d like to add or ask.