Translating business requirements into product roadmap

A brief case study showcasing how I bring high-level business ideas down to execution-level roadmap.

A brief case study showcasing how I bring high-level business ideas down to execution-level roadmap.

A brief case study showcasing how I bring high-level business ideas down to execution-level roadmap.




Product Management


Shawn Tsou (COO) Chih-ping Weng (Full-stack Engineer)


January 2023

Dashboard Sidebar Close Up
Dashboard Sidebar Close Up
Dashboard Sidebar Close Up


Following the implementation of the Electronic Medical Record (EMR) prototype, the clinic had benefited greatly from its centralised data management. The live-data EMR prototype had not only allowed the software development team to test and learn from the open environment, but also enabled the clinic to initiate a more attentive follow-up service for patients as retrieving medical records had become as easy as ever. 

The positive outcome of the follow-up service eventually led to the development of a brand-new care management service known as ĒSEN Care. This care management service provided patients with personalised healthcare programmes delivered by ĒSEN’s health coaches after their clinic visit. And the launch of ĒSEN Care was a huge success. The company witnessed an unprecedented huge boost in revenue, which made the management team start to reevaluate the business strategy. 

In order to provide a more holistic healthcare service, the management team began to explore the possibility of establishing a membership programme that could integrate the services from the clinic (ĒSEN Clinic), care management (ĒSEN Care), and other healthcare partners. The decision had inevitably shifted the original roadmap of the software development team. However, a new challenge emerged – the gap between high-level business ideas and actionable execution plans had remained wide open. After a few rounds of ineffective meetings and discussions, we realised there seemed to be some miscommunication. This is where I stepped in.

This case study delves into the process of how I successfully translated lofty business ideas into tangible product requirements and deliverables.

Define the model

Upon receiving the diagram from the management team, we understood the overall business goal for this new strategy from an operational standpoint. However, as we dived in deeper, trying to figure out the further details from the technical aspects, we soon encountered two major issues:

#1 Confusing terminology

The terminology used in the diagram was unnecessarily complicated. Each ring referred to one type of targeted audience in the ecosystem, which were registered users, clinic customers, and paid members. The terminology made it challenging to decipher and categorise their needs as there were too many layers added on each term. For example, how is the membership system going to convince registered users to become  clinic customers, and eventually paid members?

#2 Unclear scope of membership - Care management vs. Membership

It took us a while to realise that the new business segment, ĒSEN Care, was completely missing as the management team had named it “paid member” in the diagram. This immediately posed an existential question - 

Are we still building a membership system, or just a care management system? 

From our previous understanding, the care management service was a new business segment, yet the membership was supposed to integrate services from the clinic, care management, and other healthcare partners. Furthermore, usually a care management service only lasted for 4-8 weeks at ĒSEN, yet the membership was designed to be a yearly subscription. Does a “paid member” automatically become a “clinic customer” (or registered user) once the care management service is done?

The confusion stemmed from both terminology and scope issues. After clarifying with the management team, I had redefined and structured the diagram for the software development team.

The new model

I redefined the grey rings as distinct business segments, and separated the concept of membership with new pink rings. To enhance clarity, I introduced the approach of tier membership to the model and redefined the terminology for target audience as “Free member” (combining registered users and clinic customers) and “Paid member”. The new model also enabled rapid future iteration as it was significantly more flexible to move the membership rings around and reconsider what should be included or excluded from the membership program.

Define key personas and their journey 

With the newly defined model in place, we were able to proceed and identify our key target audience within the ecosystem. Breaking away from the previous terminology, the new model also allowed us to define nicher personas and paint more colours on them.  

We further eliminated the personas that were less relevant to the project and focused more on those that already existed. Around the same time, the management team had conducted several rounds of interviews with the patients in the clinic and those who had purchased the care management services. I synthesised the insight learnt from these interviews and crafted user stories for each personas. 

Define the features for the membership system

Based on the personas and user stories, I was able to define and categorise the product features. As we eliminated some of the personas from the business segments that did not exist yet, we also eliminated those related features. 

After a few rounds of discussion with engineering, clinic operation, care management operation, and the management team, I had finally come up with the final version of the feature set for the membership system.

Result & Deliverables

Here are some of the deliverables and results we had:

Product roadmap

Product Roadmap: With the overall product requirements and trajectory established, I created a new roadmap for the membership project and updated the original roadmap. Additionally, considering the expansion of the entire product line, I had also created a capacity sheet for the software development team, and brought it to the management to discuss the potential expansion of the team.

Product - Customer-facing Membership system

We eventually launched the membership system in October, enabling patients to register as members and manage their records. In August, we modified the scope of the membership system as the trial sales of the membership service didn’t succeed, effectively hitting the big pause button on several feature developments. However, since the management team believed the membership system could still play an important role in the entire ecosystem, the software development team modified the scope again and launched the membership system on time.


Besides product development, the software development team was also responsible for the website design and development. Along with the product design, I also designed and built the new pages for the care management and membership services on Webflow.

Built with Framer from Taipei, Taiwan

Built with Framer from Taipei, Taiwan

Built with Framer from Taipei, Taiwan