How partnership approach could be useful for digital health startups
After working in the digital health industry for a few years, we have come to realize that outsourcing product development poses several risks. These risks include a lack of understanding of specific niches, patient/doctor behaviors, legal standards, and weak cross-functional collaboration within the development team.
These realizations have led us to believe that healthcare requires a new and innovative approach to product development. Digital products have the potential to significantly impact patient outcomes and safety.
Have we found this new approach? Yes, we have.
In this article, we are excited to share the benefits of adopting this approach in developing digital health products. We will explain why it is important for individuals to transition to this approach.
We are not making baseless claims about this being the most effective development format in the digital health market.
I. Understanding the market and user behavior patterns: doctors, patients, and health enthusiasts
Before starting the product development process, it is crucial to understand the behavior patterns of different user groups such as doctors, patients, and health enthusiasts. This understanding helps in designing the user interface (UI), user experience (UX), and features that cater to their specific needs. For instance, it is important to know how to onboard conservative doctors who may not be accustomed to using such applications. Similarly, understanding what aspects of UI and UX to emphasize for a patient with bipolar personality disorder is essential.
Outsourcing approaches fall short because they do not focus on specific niches and lack deep knowledge in understanding user expectations. On the other hand, a product partner possesses the expertise to build a user journey that feels intuitive.
For example, when developing the Allbry application for student-counselor interactions, we created chat functionalities that allowed students to communicate with specialists while ensuring data privacy from their peers, promoting openness and confidentiality.
Moreover, when introducing chats, we corrected the long User Journey by reducing everything to the “3 clicks” rule and implemented those elements in the footer that are familiar to users in this market, based on the preferences of users regarding messengers. The latter is especially important, since in this way we reduce %User Churn and increase % Engagement due to increased intuitiveness.
Also you shouldn’t forget about focus. We’re constantly thinking about how our products will be used in the real world, and how they can help improve patients’ lives.
From the initial design phase to the final implementation, we’re always asking ourselves: Will this product make a difference? Will it improve outcomes? How can we make it better?
II. Adapting to legislative standards in Digital Health apps
It is important to understand the specific niche in order to adapt the product to the required legal standards, such as FDA requirements in the US or GDPR in the EU.
For instance, did you know that GDPR mandates the deletion of user data from applications after a certain period of time? If you were unaware, it is crucial to double-check if your product is compliant with the law.
In a partnership approach, the company partner takes into account all these nuances and incorporates the necessary standards into the product itself. In the example mentioned above, we implemented automatic data deletion from the chat system to comply with the law.
Additionally, we value FDA compliance and have outlined the steps for developing applications that meet American standards in our guide here.
III. Transparent communication and mutual error detection
In outsourcing, there is often a mindset of “you give us the task, and we simply execute it.” This means that they may implement flawed ideas without engaging in discussions where they are needed.
Moreover, in the outsourcing approach, there is rarely regular communication with the client, and the process lacks transparency. In such cases, there is a risk of ending up with a product that doesn’t meet the desired requirements or doesn’t align with market needs.
Frequent communication helps ensure that customer feedback is incorporated into the product at every stage of development. Depending on the development phase, data exchange can occur daily, weekly, or monthly.
During the initial research stage, communication with clients can take place weekly or biweekly. This communication typically involves discussing features, design, and sharing results from previous tests and early prototypes.
The duration of these interactions is determined by the fact that the partner identifies areas of growth or issues in the current idea/prototype, develops solutions, and provides estimations with deadlines. As the development process progresses, communication with clients becomes more frequent.
During the prototyping stage, communication may occur every few days or on a weekly basis since this stage focuses on developing initial mock-ups.
During user testing, daily communication is beneficial as clients provide feedback on usability and feature requests, requiring timely discussions of new insights. For the development stage, a frequency of once every two weeks can be adopted for sprint reviews.
Let’s provide an example from our experience. We developed the Microshift application, which is used for mood management and enhancing focus.
Together with our partner Roman, we had daily meetings to develop the product through joint efforts and simultaneously test it. Well, according to all the laws of an agile development methodology, we flexibly adapted users’ feedback and, through daily communication, did not do extra work by immediately changing direction if necessary.
One of the most fascinating and motivating moments was when we practiced Microshift together: we “shifted on the call” and then shared our feelings. During such moments, you realize that the true essence of partnership and cooperation is revealed, and the rigid boundaries between the two involved companies are softened.
And most importantly, such communication made it possible to make the application much faster than the partners expected. The discovery phase lasted only 2 weeks. During these 2 weeks we worked through the concept, created UX and Art Direction for the first version of the app and started tests and the development.
IV. Targeting Product Metrics with Google Design Sprints
Essentially, this is a must-have development method that enables rapid idea validation and prototyping with real users.
By using a design sprint, a company with Digital Health Product can benefit in several ways:
1. User-oriented experience (important!): by incorporating user feedback early in the design process, the team creates a prototype that meets the needs of the users and provides a better user experience.
Users will not leave onboarding of the app during the initial validation, if they take care in advance that the verification on users takes place at all.
Thus, we already see from the very beginning which metrics can and should be increased. For example, Retention, User Churn, Engagement and Total number of registrations.
For example, when we conducted User Tests in the Allbry application, we discovered a serious defocus and high cognitive load among users. They couldn’t find the necessary information and features in the application, they took a long time to complete the tasks, and it was difficult for them to navigate.
2. Reduced development costs: by testing design concepts with users before development, the team can identify potential issues and make changes before costly development work is done.
3. Faster time to market: by using a design sprint, the team can compress the design and testing process into a short period of time, allowing the product to be developed and launched more quickly.
4. Increased stakeholder buy-in: by involving stakeholders in the design sprint process, the team can ensure that everyone has a voice and is invested in the final product.
What Design Sprints entail?
1. Vision formation, with setting up ideas and metrics.
2. User testing and a minimal prototype.
3. Creation of UX Design based on user testing and best business practices.
4. Subsequent User Tests on an improved prototype version to compare performance.
5. Software Development and UI.
More about this method we wrote here.
V. Proactivity, task planning and success control
Outsourcing lacks in-house specialized product experts who can bring new ideas to the product, so the responsibility of achieving market matching in such cases falls on the client.
A partner Studio, on the other hand, is a different story as it encompasses a full-cycle team, including not only programmers and designers but also product specialists. These specialists generate ideas and even critique them if they see that a feature won’t succeed in the market or if something is overlooked.
How does such a team work internally? We have outlined this process in more detail.
I. First, the Product Partner asks sprint participants to estimate the number of hours a particular task will take, how difficult it is, and their confidence in completing it. Tasks can be prioritized using a system like RICE.
II. After prioritization and task assignment, the company adheres to the following rules:
1. Looks at the participant chain and identifies bottlenecks.
2. Shortens the timeline and sets the sprint deadline 1–2 days earlier.
3. Adds a buffer (bonus) at the end of the project as an incentive but makes it time-limited.
4. In case of deadline delays, seeks and utilizes additional resources.
5. Conducts daily check-ins (at the same time) in the form of 15-minute calls.
III. Next, there are check-ins and questions (without criticism; criticism and additional questions can be addressed in a separate call by arrangement or at the end of the sprint):
1. What did I do yesterday to achieve this goal?
2. What will I do today to achieve this goal?
3. What is hindering me from achieving the goal?
4. Key point: Maintain focus on customer value.
In addition to daily check-ins, there are options for weekly (1 hour), bi-weekly sprints (2 hours), or monthly work (4 hours) where the following questions need to be addressed:
1. What did I accomplish during the sprint?
2. What did I not accomplish?
3. Any feedback received?
4. Next steps?
IV. After discussing the sprint, a retrospective is conducted:
1. What went well in the work?
2. What needs improvement?
3. How will we specifically try to improve the next sprint?
V. At the end of the retrospective, an improvement plan is proposed. The ideal sprint duration is 2 weeks. The result should be something tangible.
But that’s not all! We have detailed this approach in our e-book, which showcases the focus on user feedback and product metrics with practical examples.
Download a comprehensive guide to developing Digital Health Products with a new approach.
If you are interested in our approach and you have a Digital Health idea or a product that needs to be scaled, then you can email us for a free consultation on how to create/increase user engagement and revenue in your product.
