Behind the Scenes: 9 Steps to Creating a New Feature

As one of the Product Managers here at SimplePractice, it’s my job to oversee the ideation, research, development, and release of our product features. I work closely with our customers and other internal team members to make sure the platform meets our customers’ needs. 

My role places me at the center of it all, so I know what it takes to release a new feature. Changes to SimplePractice are a multistep process, so I’m pulling back the curtain on how we take a feature from an idea to a powerful feature or product update that’s used every day by our customers. Here’s how the “Sex and Gender Fields” product update happened.

9 steps that must happen before a new feature release:

1. Listen to customers.
2. Collaborate with team members.
3. Research. research. research.
4. Draft first proposal and get customer validation.
5. Write the requirements.
6. Build the feature.
7. Run through early-adopter testing.
8. Communicate with customers.
9. Release it!

1. Listen to Customers

It can be difficult to choose which feature or project to work on next. Do we want to build something exciting and new? Or do we want to work on an existing feature to make it even better? Yet the one question that’s always front of mind is: what do our customers need?

Drawing upon help requests, our SimplePractice Community on Facebook, and the Ideas and Suggestions board on our Forum, we identify the topics that are important to the SimplePractice Community and make those a priority.

In March 2019, that topic was how the SimplePractice software collects gender information. There was a post on our Ideas and Suggestions Board where customers were expressing their need for more flexibility around gender options. That post gained more than 60 comments from SimplePractice customers who were sharing their stories about how the current form didn’t fit the needs of their practices and clients. 

Around that same time, members of the SimplePractice Community on Facebook who work with and are members of the LGBTQ+ community voiced their opinions about the form. Our Chief Operating Officer (COO), Fletcher, noticed the trend and brought the topic up at our weekly product meeting. 

2. Collaborate with Team Members

Every week at SimplePractice, members of the product, design, engineering, and customer success teams gather to discuss which projects to prioritize in the upcoming week’s work. During one of these meetings, Fletcher brought up the concerns of the community and encouraged one of us to develop a proposal around a better way to collect sex and gender information. Unanimously, the meeting attendees agreed to prioritize the project. I volunteered to own the project and set off to figure out a solution.

3. Research

My first step was figuring out what Meaningful Use policies had to say about collecting gender identity information. When making even a seemingly small change in SimplePractice, our compliance team works with lawyers and legal counsels to ensure we remain compliant with the various government bodies and legislation surrounding personal health information (PHI).

I discovered organizations like the Institute of Medicine and The Joint Commission started advocating for the collection of gender identity information back in 2011. 

In October 2015, the Centers for Medicare and Medicaid Services (CMS) and the Office of the National Coordinator for Health Information Technology (ONC) agreed, and passed legislation that placed the collection of gender identity information under Meaningful Use. However, according to a 2018 article in the Journal of the American Medical Informatics Association, adoption of those recommendations has so far been limited across healthcare organizations and EHR platforms.

Now that I knew that we could collect that information, the next question was: how do we do it?

Luckily, I was able to draw upon 20+ years of research by LGBTQ+ health centers across the country. A 2012 joint report by The Fenway Institute, Brigham and Women’s Hospital, and Harvard Medical School—as well as a 2014 field guide from the Joint Commission—put together best practices for collecting this sensitive information

Both recommended open-ended fields for clients to self-identify their gender, presentation, pronouns, and any other identities that matter to them.

I knew SimplePractice had to offer the structured collection of binary sex data for insurance billing purposes. Per the recommendations of the available research, I decided to name that field “Sex” instead of “Gender” and provide context for clients around why that information was collected. One of our main priorities is to make sure claims get processed and paid. For members of the LGBTQ+ community, this bridges treatment gaps and expands accessibility to underserved groups.

4. Draft First Proposal and Get Customer Validation

Research in hand, I developed the first proposal to bring to our product development meeting. I structured the proposal around three questions we ask before starting any project:

• Why are we doing this?
• What is changing?
• What do we need to build?

I brought the presentation before the other members of the product development team and walked them through the proposed changes. The proposed changes included renaming the “Gender” field to “Sex”, limiting the options to those required by payers, and adding a free-text entry field for gender information. 

The team had some questions. Should we consider a more structured gender information field in the future, like our new Referrals report, for version 2.0? What about customers who didn’t want to collect this information. Would we allow them to disable the gender information field on their demographic intake forms? 

Before answering any of these questions, we decided my next step was to confirm the proposed updates would actually help the customers calling for changes around our gender fields. It wouldn’t make sense for our designers to work hard on a prototype only to discover later that it wasn’t what customers wanted.

To get in touch with these customers, I contacted our Community Manager Gillian. She reached out to our Facebook Community to see who would be interested in answering some questions about upcoming changes to SimplePractice. Of the ten customers who responded, I got a chance to speak with seven.

On each call, I introduced myself and walked them through the updates I had in mind before opening it up to their feedback. I was surprised that everyone loved the free text field and expressed no use for a structured way to collect their client’s gender, pronouns, and other aspects of their identity. They reiterated how important it was to clarify why “Sex” had to be limited to binary options. They also informed me that their trans and non-binary clients were familiar with these kinds of bureaucratic allowances—so long as there was a reason given. 

I learned that “Gender Information” felt clunky and should instead be “Gender Identity,” and that we had to remove “preferred” before “pronouns” because they aren’t preferred. They are that client’s actual pronouns. 

Finally, I asked an open-ended question about their experience with SimplePractice to see if anything else jumped out as a candidate for our next update. I took notes for the product team, and promised to keep them in the loop as these features were built.

5. Write the Requirements

Research in hand, I contacted our Director of Growth Design, Jeff, and gave him the information he needed to start designing how these changes would look within SimplePractice. While he worked on the designs, I wrote the requirements for the feature. 

In product development, requirements are a comprehensive description of how a new feature should work. What happens if there’s an error? Who can see this? If there are links, where do they lead? Once an engineer builds a feature and it goes into testing, quality assurance (QA) testers use the requirements to ensure the feature works as expected. So if something doesn’t work once it’s released, the fault is with whoever wrote the requirements.

After writing the requirements, I submitted them to our product development team for approval and refinement. Every aspect of the feature is considered—from visual layouts, to copy, to how the existing gender data will be moved with the release of this new feature. This means the approval process can take some time as the requirements are fine-tuned and cleaned up.

Once the requirements and designs received approval by the whole product team, I sent the requirements to our developers so they could start their work.

6. Build the Feature

The engineering team at SimplePractice works quickly, and after finishing one project, they hop onto the next one. The developer in charge of the new “Sex and Gender Identity Fields” was Andrey who worked on the Wiley Treatment Planners and the Referral Report, to name a few. We worked closely to make sure everything was accounted for in this project. 

The feature was broken down into three distinct sections: client-facing changes, customer-facing changes, and updates to the SimplePractice mobile apps. As Andrey worked on the feature, one of our QA engineers reviewed how the feature worked to make sure it matched the requirements I provided. QA engineers not only see if a feature works, they actively try to break it by running it through any possible scenario to ensure its durability. The QA period is an integral part of the SimplePractice development cycle.

We also made sure these new fields would appear on both the Android and iOS versions of the SimplePractice mobile app. We have an entire mobile team working on these apps. And when a feature appears on both the web and mobile versions of SimplePractice, it means two teams worked in tandem to make it happen. Our mobile developer Oleksandr built the feature for each platform, and Yana ran QA testing, so customers would have a seamless experience going from their computers to their phones.

Once a piece of the feature is built, tested, and approved, it can be turned off and on in a SimplePractice account by a member of the product team. And that’s when the next stage of product development starts—early adoption.

7. Run Through Early-Adopter Testing

While our QA team puts in a lot of work to make sure that new features work as expected, the ultimate test lies with our customers. Does this feature fit into or enhance a practitioner’s workflow in SimplePractice?

I first reached out to the same customers whom I consulted with earlier to grant them access to this new feature. During this stage, our team learned that the first version didn’t meet customer needs in a few ways. This gave us time to make necessary changes before it was released to the public.

8. Communicate with Customers

Once a feature is ready to release to every SimplePractice customer, our marketing and customer success teams make sure our customers have the resources they need to understand and use the new feature. The marketing team determines how to spread the word about the new feature. 

Then, our knowledge team makes sure the Help Center offers step-by-step instructions for customers looking for more information on how to access and use this feature. I also work with the entire team to show them how the new feature works, so they can answer customer questions and provide personalized support.

9. Release 

On the day of release, it can feel like the end of a long journey, but it’s only the first step. I always keep an eye on our Facebook Community, our Community Forum, as well as chats and emails answered by our customer success team for more customer feedback about how we can make the next version even better.

10. And Repeat

SimplePractice takes the time to work through all of these steps to ensure the best experience for our customers. The number one reason we build something new or change something current is because of the feedback we receive from our customers. We couldn’t do it without you!

For more information on this update, read our Help Center guide.

Join the conversation today by joining our Facebook Community and posting on our Community Forum.

---