Behind-the-scenes of our product process: how we create and improve our features

Being part of a team that’s creating a product for mental health professionals (MHPs) is hugely rewarding and exciting to me. 

Although I’ve spent nearly a decade in the tech space and have picked up terms like triaging user needs, deployment, and iteration along the way, I realize these concepts might feel unfamiliar to those of us trained to understand people rather than technology. With that in mind, I thought it would be helpful to share some insights into the product process and how we work in this space.

In this article, I’ll walk you through what happens between when you first post a feature request to us and when we deliver it. After all, you’re our co-creators!

What happens between a feature request and its release? 

This is a great question! And the answer is that it starts with you, our MHPs. The very first step is trying to understand our audience’s needs and challenges. 

Our community is a great resource for us. Some of our members are very tech-savvy and enjoy being the first to try out new functionality, while others may not even know that they’re making a feature request. Think of it as giving us feedback about something you need in the product that isn’t currently there, or making a complaint, or observation. All of it is very valuable because it gives us insight into what you might need.

All of this feeds into a pre-existing product roadmap that is based on our understanding of user problems from within the mental health space. When you have an idea for us, it needs to be considered alongside other features and improvements we’re already working on. Our leadership team then decides where our focus should be, and this is evaluated alongside other business goals, as well as making sure we’re hitting our mission and overall product strategy.

With enough planning and research, there shouldn’t be many big surprises. However, anything that’s new and hasn’t been accounted for in our roadmap will also require very careful consideration of PHI, confidentiality, and ethical implications. 

As with any new digital product, things can take time when they’ve not been done before. The AI-in-therapy-space is evolving, and we’re the ones evolving it together with you! 

A few highlights of our internal process – step by step

Let’s get right into it! 

1. We listen to your needs and feedback

We may directly get an idea from you or receive feedback about existing features that may lead to new ones: like being able to customize our progress notes. The user need is then defined, i.e. greater flexibility when it comes to note creation. It is not yet called a feature, not all solutions are, and we simply try to understand the problem or opportunity in depth.

2. Next, we prioritize

Although it may seem easy from the outside, we receive many feature requests from different mental health professionals who ask us for different things. And of course, the needs of solo providers differ widely from large group practices – and we have to consider both. Once we receive your feedback and identify the need, we re-prioritize our focus. With many requests coming in, we carefully juggle our team’s capabilities with our users’ needs and our overall product strategy. We also budget space on our roadmap for new requests that are seen as a high priority.

3. Then, we analyze – as a team

‍Once a need is identified and selected as a priority, the team gets together and shares ideas about how it could be addressed. We consider it from all angles: clinical, design, engineering, and product. If the solution is a feature, we go on to the next stage. The clinical team is most important.

• The clinical team brings insight from a mental health practitioner perspective. For instance, using the example above, this could mean identifying all the relevant sections in a note a clinician will want to customize, and then considering how this may differ within our audience subgroups (i.e. therapist vs. psychiatrist). They may also consider other contextual therapy-based or session-based information. This is important because creating quality products doesn’t happen without a deep understanding of the audience.
  
  
• The AI team then works closely with the clinical team and considers any AI-related implications, such as the type of prompts required to allow the language model to identify the therapeutic interventions used in a session. For instance, for our Text-to-note feature, we had to incorporate a comprehensive understanding of therapeutic modalities. Otherwise, we wouldn’t have been able to correctly document them from client sessions. Can you imagine covering all of them? Our team invested significant effort to ensure we had high-quality, up-to-date information on these modalities and could accurately recognize all their techniques and related interventions. Once we test the modalities by using them in this  feature, and monitor how they perform over time, we’ll then implement them in other areas of the product too. That’s why certain features can take a little while! ‍

4. We communicate and align

‍We carefully document everything as it is worked on so that the team is aligned, and use the same documentation for the entire feature process so that different teams can refer to it. We may also seek out legal, privacy-related, or country-specific information at this point. And, we have demo meetings for the wider team (developers, AI engineers, marketing, sales, and support) so that everyone can understand the features we’re building within the therapy context and can provide further ideas or insights.‍

5. Moving on to design and copy (that’s my jam 🙂)

We try to make it fast, easy, and intuitive to use Upheal, and that starts with every feature going through several rounds of the design process (design iterations). The designers create a prototype or design solutions, ideally with our product writer, and share these with the team. Our team, including a MHP, then gives feedback leading to either more improvements or a feature that’s ready for release! We strive to fit seamlessly into a practitioner’s workflow –  our mission is to help MHPs find balance, and we certainly wouldn’t be living up to that if a single action consisted of many complex steps or the UI copy was unclear and confusing. Throughout these earlier stages, we also work on feature naming, marketing, and business-related implications such as which plan a new feature should be a part of, and put together the necessary Support articles.

6. Engineering does its magic

‍The engineering team is present from the onset and discusses ways that features can be made to work as intelligently, quickly, and securely as possible. Many of the features we build are complex technological endeavors spanning across multiple engineering departments. Taking our various dynamic note sections as an example, the LLM team has to consider the whole AI architecture first, the backend team handles the note processing pipelines and security aspects that will be required, and the frontend team works on creating a helpful, seamless UI. It’s important to consider the product as a whole. One change, such as having a Custom note template feature, requires multiple changes to several product sections: the Settings, the progress note section itself, and the menu, which can be a lot of work for our engineering team. To validate our design concept and test a new feature, we usually show it to our community members first and organize interviews and observability tests. After that, as quickly and carefully as they can, our engineering team implements and deploys (for some reason, this word always makes me chuckle).

7. Documentation

In addition, we document the feature for our Support center, ensuring that we can explain how to use it to our users and answer any additional questions they may have. Using Upheal should be easy, transparent, and ethical.

8. Quality assurance

We test everything before releasing our features. This is so that we know everything functions on the backend as it should as well as is ready for you, our users, in its best possible state and with no disruptions.‍

9. Marketing efforts and communications

When the feature is released, you’ll get an update from us that it’s live and ready to be used in the product! We spend time crafting our emails and social media messaging so that it’s easy for you to understand what’s changed, why, and how it will benefit you going forward. Some of our earlier efforts, like naming and positioning will hopefully make their impact at this point, helping you to better understand and navigate the product.‍

Release and iteration(s) 🎉

The process never really ends. We make sure to update or improve our product whenever necessary, and continue to improve it if you provide further feedback after release! This is called the MVP approach, and we try to release fast, with the mindset that we will still learn and adapt based on our customers’ feedback. This often happens in new product development. And of course, as you’ve already learned we may have to re-prioritize existing tasks to do so. But that is the product circle of life!

So what do you think? Did you expect this?

‍We hope that gives you a little insight into the product process and all the things we do between when you first submit an idea to us and its release. Although it may feel slow at times, we do like to take our time to make sure that we’re creating a highly accurate and informed product since anything less would be unethical. Sometimes, our process is fast, and at others, it opens many discussions, checks, and additional tasks that we need to complete before being able to bring your feature request into the world. And being us, we don’t like to release something until it’s truly going to be helpful to you. Did our process surprise you? Let us know!