When you start conceptualizing your product, it is good to let the imagination run wild. Still, it is essential to add a bit of pragmatism to your product roadmap - you can’t be everything to everybody.
Assuming that you have a good grasp of the competitive landscape, you need to identify exactly what makes your product or service unique and tie that into an understanding of your expected revenue streams e.g. having fancy and comprehensive admin functionality is not directly providing tangible benefits and value to users (in a b2c offering). Needless to say, the features and functions you plan to build in your product must support the prioritization of the revenue streams.
Once you have your product roadmap, you have indeed challenged yourself by applying some limitations. You should take an additional view of the product ecosystem to which your product belongs. That will provide a better perspective and validation of the roadmap but will also provide input for 2 further important considerations:
Use the product roadmap to inform the direction of your product architecture and infrastructure.
From the product roadmap, it is possible to elicit what I tend to call ‘Architectural drivers’ - the critical part here is that you do not want to ‘over-dimension’ or ‘under-dimension’ your technical approach.
CX or customer experience is vital. Switching costs from SaaS products are not very high, so you will have to be on your toes with regards to providing a superior user experience… and don’t forget that the user experience starts from your website/in the app store and extends all the way to problems/issues resolution (customer service).
Translating your roadmap into wireframes is usually the way to go about it. Suppose you have the opportunity to create a clickable prototype to show early investors, FFF friends, family & fools. In that case, you can get some potentially great feedback and increase investor interest.
Nothing particularly new here, right?
However, the thing that always seems to end up as an afterthought is tangible measurements of how your product is being used, where users drop off, what they are not using, their issues, etc. It tends to be ‘we will, of course, apply google analytics’ and on to the next point on the busy schedule. Knowing how many conversions/purchases you have is not enough.
We would argue that events mapping, i.e., the analysis and determination based on your wireframes and designs, are almost as critical as a scalable and well-thought-out technical architecture. It is vitally important that you set up the right measuring points from the get-go and include those as part of the “definition of done” when you get to the development of your product. Furthermore, you need to have a clear vision of which tools you will use for data collection and analysis. This step is fundamental, although typically marginalized. CX/UX analytics is actually a thing.
For the sake of happier users, efficiency of future product development, and to satisfy investor questions, you must be very well versed in the fancy abbreviations of the general product metrics of SaaS products. You must be able to back that up with real data.
Always consider CAPEX vs. OPEX; what does that mean in reality?
Only invest CAPEX in areas that are a differentiator for your product, i.e., IP. Don’t spend cash on reinventing the wheel e.g., custom build components and services that can be consumed natively from a commercial cloud (as there obviously is no product edge in that) - on the contrary, the edge is to fully understand what’s available and use that in our architecture (increase speed of getting to market, reduce CAPEX and only pay when you have usage of your product (OPEX)
And regarding reducing OPEX - make sure that you fully understand the various startup accelerator packages that the commercial clouds offer.
Don’t go for exotic frameworks or languages unless it is absolutely necessary for building your product.
Point: When you need to scale and increase your engineering team, you would want to be able to dive into a larger pool of specialists for the following reasons 1) cost, 2) reduce keyman dependencies, and typically it will also reduce the cost of ongoing maintenance.
Compliance & Documentation
Utilize cloud-native services to the fullest bla bla
If you are mindful of the above, you will be able to:
Project managers are there for results to be delivered, and QA leads are there for those very same results to run like clockwork.
Project managers are there for results to be delivered, and QA leads are there for those very same results to run like clockwork.
