The balancing act

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:

1. Are there integrations/connectors to other products or platforms that are crucial and should be considered in the technical design?
2. Can I leverage the ecosystem for my go-to-market plan, e.g., standard connectors, to establish peripheral products in the space I’m entering?

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.

User journey

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.

Architecture and Infrastructure

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. 

Choice of the tech stack

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.

Don’t forget that you need to operate the product

Compliance & Documentation

Utilize cloud-native services to the fullest bla bla

Summing up

If you are mindful of the above, you will be able to:

1. Provide clear USPs for your product and demonstrate a roadmap where you have a balanced market position
2. Evaluation of ecosystem opportunities and organic growth/user acquisition via partnerships within the ecosystem
3. Demonstrate a clear cost/benefits understanding of your R&D budget
4. Build vs. buy-in perspective of product adoption and success (speaks to profitable scaling and spending of funds where there is a clear return)
5. Risk and cost mitigation in your technical product design 
6. A data foundation demonstrating your ability to analyze user behavior and consequently turn that into actionable improvements
7. Regulatory compliance (Data shield, GDPR, HIPAA, etc.)
8. Financial forecasts of your company based on real measurable parameters