A product plan is a really great method to set the long-term vision of your product (or products in my case) and set an objective to strive towards. In this post, I will just talk about my approach to creating product plans and give you an example of it.
Background
I have been involved in My Day To-Do for the last few years and it’s grown through the years i.e. people have come & left, downloads have almost quadrupled, user retention has increased and plenty of user feedback has been collected. This startup has had a lot of casual help the last few years i.e. contractors coming to work on a project and leaving after it’s done. E.g. an MBA grad to prepare a marketing strategy, a Chinese native marketing officer to execute the China market strategy, designers to improve the app UI, a team of translators to localise the app to 7 languages, etc etc. Among other things my duties here also involve software engineering and in the last couple of years, I had been thinking about ways in which I could manage my time until I got to know about product plan . A Product plan is a great way to compartmentalize your work or as we say in software engineering, ‘separation of concerns’.
The ‘Eureka’ moment
I don’t have an MBA and my background is in Computer Science and that too ‘hardcore’ computer science which includes AI research in video games and robotics. I have researched on supervised learning methods with algorithms such as Neural Networks, Evolutionary Algorithms and Support Vector Machines. Therefore when I first discovered the Product plan , I was like “woah!! this is so cool”, which it “totally” is. I find the product plan synonymous to the “separation of concerns” design principle of which component based software engineering is an application. So according to me, a product plan and component based software engineering are related at a very high level, whereby you identify and compartmentalize your solution! Given that concept in mind, a product plan is not that different from a class diagram, take a moment and try to how to draw a class diagram, a similar thing applies to creating a product plan . To conceptualize and implement a product plan , you need to consider various cross-functional teams. Hmm, maybe I am not explaining the analogy as clearly as I could? Anyway, let’s examine a product plan in more details.
Product Plan
The Wikipedia definition of a product plan is it’s “an on going process of identifying and articulating market requirements, that define the product’s feature set”. So it’s a continuous document about determining how well of a “market fit” a given product or a feature actually is. There can also be more than one type of product plan, the ones I know of are, an Internal product plan and one for external stakeholders.
External stakeholders
External stake holders are those who only care about the performance of the business or are affected by the performance of the business. What that means is that they do not need to know the nitty-gritty of how a particular feature is implemented, but rather how that feature will affect the business performance. So a product plan for external stake holders would typically include high level information for each quarter. For example,
- Feature X added in first quarter of 2019
- 20% increase in new user sign-ups & 40% increase in user retention in the 2nd quarter
- 60% increase in revenues by the 3rd quarter
This product plan would be something like horizontal bar chart with colored bars representing the objectives in each quarter. External stakeholders are important to the business, hence it’s important to keep them engaged and informed about your product strategy via a product plan.
Internal product plan
In this one you focus on the nitty-gritty of it all and mention specific details on the execution of certain tasks. I recently made one of these for internal use at My Day To-Do, you can have a look at the full product plan by clicking here . In that product plan you will see how I have planned or scheduled the My Day To-Do updates as well as some new apps that we aim to release based on some user stories.
This product plan is for internal organizational use and I think it may look a little more like a project plan but it is something that we use here.
In the first year and My Day To-Do being an app based startup, the process at My Day To-Do was , I think of a new feature, make a plan for it and start coding it in from the next day. However as My Day To-Do grew and an MBA graduate started working with us and did his ‘MBA things’ such as a detailed competitor analysis, market need of the feature vs product need etc etc. It was time for us to take a step back and adopt a more careful and thoroughly planned approach to the problems we were solving by adding those new features to our product. Simply put, take a step back from the “shoot first, questions later” approach to adding new features.
Summary
Ok, so that’s a wrap on this short blogpost, if you have any thoughts on this, then please leave us a comment and let us know what you think. Also, if you can share any of your insights on product plans or product roadmaps, then please do write in the comments too.
As usual, if you find any of my posts useful support us by buying or even trying one of our products and leave us a review on the app store.
Comments