I spent this past week with some incredible entrepreneurs as part of the Google Launchpad Accelerator program in Singapore to support the graduation of their Asian participants in class 3. It was an extension of the mentoring we provided them back in February in San Francisco, primarily to assist in their OKR Recalibration for the next quarter. Seeing the progress of these great startups, and meeting several new ones who are being incubated in the Singapore startup ecosystem was an incredibly energizing and educational experience which I will be talking about further in the weeks ahead.
During our mentoring session with a local startup not in the program, an expert agile development coach, Muthu Rajamani took lead in coaching them on a more structured and efficient approach for their design and development processes. As is often the case in maturing startups, we invariably hit upon the difficult challenge of prioritizing feature development, so I began looking for my article on my personal approach to software development prioritization.
From my own personal experience as a product manager founder building several products with no coding skills and minimal cash, this was a challenge with which I am all too familiar. While building Alynd I developed a fairly straightforward method to determine how to prioritize a development road map. Turns out, I never actually wrote the article, so I am doing that here to share with everyone. I wasn’t so sure that it would be useful to anyone else, but Muthu told me he liked it, so I promised to finally publish this.
In a resource strapped startup, whether in early stages or inside the proverbial tornado, making choices such as this is a weekly if not daily occurrence. There is so much to do, and never enough time to do it all as quickly as we would like. Of course, choosing which stories within a broader epic is often easily accomplished as a matter of understanding the dependencies and holding to the course laid out in the road map of what has been promised to customers, investors and other stakeholders. But when choosing between two stories or epics that are seemingly of equal importance, flipping a coin is not a good option. While you could look at potential revenue impact or estimated value I felt that a more holistic strategy would be best.
This is how I came to develop the 5 V’s of Software Product Management Prioritization. I hope you find it helpful.
Vision: Is the particular feature or module a core component of the vision itself? Does it advance the big idea at the heart of the product itself?
Valuable: Is it something that is of value to the company itself? Does it reduce friction in the product in some way or provide a differentiated experience from competing products in the market? Will it be valued by a large or small number of users?
Validated: Has it been validated through user requests or feedback? Is it something you know that your users actually want?
Viable: Is the effort required something that is viable? I.E., is it something that we have the knowledge and ability to do or is it an entirely new, untested technology or concept? Can we actually do this in a relatively short period of time or are there many unknowns relative to the technical feasibility of the code?
Visible: Is it something that the users (and investors) will be able to see in the application and recognize it’s value? Where they will take notice of what you have actually accomplished? While decreasing page load times and decreasing CPU loads is certainly valuable and often necessary, is it enough of an improvement to make a noticeable difference?
The few occasions I used this method building Alynd, I mostly was able to take a binary approach to making the decision where it was clear that one choice met all 5 criteria and the other choice did not. That said, there will often be two or more stories competing for attention that meet all these criteria and need to be further differentiated. In such cases I believe a simple scoring of each criteria for each story on a scale of 1-5 would be useful, while also considering viability more closely together with associated effort estimates.
In thinking further about this over the last few days, I hit upon one other criteria which might be considered, not part of my original approach, but the more deeply I have gotten into OKR’s over the past couple of years, the more this makes sense. It is in regards to the ultimate manner in which we can determine if we made the right choice.
Verifiable: Will it be possible to know whether or not this choice was indeed valuable to the company and to the users? How will be know if it is or isn’t? What’s the measure of success and what qualifies as a successful effort?
Clearly there is a lot more underlying this prioritization process, and it needs a wider effort of experimentation and iteration to refine further. I hope to explore this with you in the comments or in direct conversations. So what do you think? Does this make sense? Can you apply this to a current prioritization challenge and share the results with us? I would love to know if this works for you as well as I imagine it should.
