Lessons and Learnings from Launching a New Product with a Remote Team "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs December 12 2020 True distributed teams, New Product, new product development, Product Development, Product Development Process, remote teams, Remote Working, Mind the Product Mind the Product Ltd 2160 Photo by Kaleidico on Unsplash Product Management 8.64

Lessons and Learnings from Launching a New Product with a Remote Team

BY ON

Mira is in the final stages of launching their new product, Mira Plus. While the planning began well before COVID, the final stages have been overseen by teams that are not only located in different countries, but also filled with employees working remotely for their first time.

As a company, Mira is divided between the US and China with teams spanning both locations. The division allowed us to be semi-prepared for working with colleagues in different locations, but still challenged by the extra layer of coordination needed to accommodate everyone now operating from their homes.

The teams that contributed to this new product included marketing, bioassay research and development, instrument research and development, mobile phone application research and development, registration, production, and quality assurance.

In this post, we will share the challenges, failures and some solutions to issues we encountered as we developed, tested, and launched this product in a remote environment.

Product Background

Mira Plus is a female hormone monitoring system which includes Mira Fertility Plus Wand, Mira Analyzers, and Mira Mobile Application.

The Mira Fertility Plus Wand is an Estrone-3-Glucuronide (E3G) and Luteinizing Hormone (LH) hormone test wand that measures both hormones from a urine sample. This data is then sent to the Mira App where it is stored and analyzed based on predetermined ranges. By tracking both LH and E3G, Mira Plus can identify the onset of a woman’s fertile window earlier than other tests.

Development Challenges

Our product development process is composed of the following broad stages:

  • Market research
  • Product design
  • Product development

Of course, bringing new products to market requires the coordination and cooperation of multiple departments – often across multiple locations, depending on where the product will be available. In the case of Mira Plus, our market is global and our team spent considerable time researching trends, demands, and requirements.

Market research

The research needed to plan, build, and launch Mira Plus was immense and would have been a challenge under the best conditions. Generally, the goal is to have our marketing teams put together data on our target markets and meet in person to discuss their findings.

Traditionally, our researchers and marketers took a very collaborative approach to this process – frequent in-person meetings, with the goal of distilling findings down into a document that was both comprehensive and thorough. The high bandwidth of communication and synthesis that comes from being co-located makes this process very efficient.

Photo by Kaleidico on Unsplash

This obviously wasn’t possible for most of 2020, and resulted in a delayed time table as we struggled to not only do the research in a more individual environment, but also consolidate the learnings into something actionable for R&D.

Other than delays, this fragmentation of the process can also lead to “leaks” and gaps in information handover. For example, it ultimately led to us misinterpreting how phone numbers from different devices were stored and used by the app, which further delayed our testing and launch.

Product design

According to market research and demand, we set the following goals for Mira Plus:

  • Add detection markers on the test strip to increase the time for ovulation prediction.
  • Improve the interpretation functionality so that it can identify the specific value of the detected hormone.
  • Improve how we interpret the values in order to customize user results.

After drawing up the blueprint of the new product, the marketing department in the US communicated with the Chinese R&D team to determine the key details of the new product. In an attempt to save time while maintaining consistency, we put communication into three categories:

  1. Key communication: The key information related to the product requires the team to create shared documents for product specifics that will be used in all meetings.
  2. Detailed communication: When it comes to the details of the product, the relevant personnel will first communicate through emails and chat before meeting virtually.
  3. Daily communication: The daily progress of product development is carried out via email.

This arrangement ended up working quite well but was still full of challenges due to the learning curve associated with moving from virtual, in-person meetings to shared documents. Even with a history of working across teams in China and the US, it was an adjustment to prioritize feedback left within a shared doc ahead of virtual calls.

Product development

Due to the relative newness of E3G testing, we faced quite a few challenges during the development process, most of which were created or compounded by an entire industry trying to figure out how to work remotely.

Antibody partners

One of the hurdles of being a distributed team is that our logistics are inherently more complex than co-located teams. This is somewhat true in terms of information, but painfully true when it comes to moving physical materials around.

At the beginning of the development of Mira Fertility Plus Wand, we encountered a huge challenge when it came to E3G antibodies. Fundamentally, choosing the right E3G antibody was the determining factor for whether or not this product would be valuable to users.

Logistical complications, and the associated costs in terms of time and money, are just an unfortunate trade-off when your product team is working remotely.

At time of writing, there are very few suppliers of E3G antibodies, and the companies that could deliver the antibodies had increased prices and delivery times, due to manufacturing limitations imposed by COVID-19.

While we considered making the antibodies ourselves, the associated costs and setup time pushed us to partner with an external company and accepted their extended timeline. Logistical complications, and the associated costs in terms of time and money, are just an unfortunate trade-off when your product team is working remotely.

Unknown testing standards

As we’re working with an emerging technology, it’s worth mentioning the lack of testing standards or control products in the market. Our R&D team was split into three groups who focused on user expectations, product development, and regulation adherence. Without clear benchmarks or standards in the market, the team had a harder time establishing clear user expectations around the experience, the kind of data we needed to be processing, or what we’d need to do to certify our medical device.

This would have been a hurdle for any product team but, as with our market research, co-location would certainly have made it easier for the team to quickly align, ideate, and move forward with clear goals. As it was, this ambiguity across three different key areas delayed the development of the process the wand would use to communicate with the analyzer and app.

Testing Challenges

Our entire testing phase is divided into alpha testing and beta testing and is conducted by two different teams located in China and the US. Both stages were met with challenges due to each team (and testers) working remotely.

Alpha

Alpha testing is conducted in-house by the Chinese team and focused on product performance testing. Testers are required to perform multiple measurements in the same day to verify product stability. All testers are invited to enter an online communication group in order to share feedback and the R&D team collects the information in the group while debugging the product.

In the alpha test, the biggest problem we encountered was operational differences. Testers are usually invited to the office to try the product in a controlled environment with ample instruction – their feedback is recorded and challenges with the product are noted.

As a quantitative product, the requirements for operation are relatively stringent, and trying to oversee precision testing while remote was a challenge. In response, our app and biotechnology R&D teams collaborated to create a detailed operational guide, bridging the gap between testers and the Mira team.

While one of the goals of alpha testing is to generate the first version of a user’s guide, it was the first time we had done a guide to mitigate the risk of testing errors!

Beta

Beta testing is conducted in the United States and focused on user experience. The marketing department issued questionnaires to screen candidates, and selected users who met the requirements.

Like Alpha testing, initial Beta testing is usually done in-person and closely observed – impossible when the team was forced to work remotely. To combat this, the Mira team did initial testing 1-on-1 via phone or virtual chat, and created an operational brief that was provided to all testers before scaling the trial up.

The biggest challenge we faced during beta was a gap in our understanding of our participants’ technical context. As mentioned earlier, our market research had failed to identify how different devices store and present phone numbers to apps, leading to some testers not being able to operate the app as intended. While Beta testing was inherently harder than usual due to the lack of participant – tester co-location, we definitely felt the impact from “leaky” processes earlier in our development pipeline.

Launch Challenges

Each of our target markets had different requirements for medical device products, and the acquisition of pre-market licenses varied considerably.

The biggest challenge we faced during the product launch stage was coordinating the requirements of the US market to the app developers located in China. This was compounded by the remote structure of the US team who needed to create processes to capture, store, and convey the requirements back to their Chinese colleagues so the appropriate updates could be made.

The communication structure we defined early in the process actually worked against us here, as it slowed things considerably. Not only was the US team relying on shared docs to convey product feedback to China, but the entire US team was coordinating via doc as opposed to in person.

The result was a delayed launch in the US as our marketing team did their best to capture user feedback, match it with US requirements, and pass it back to China in order to be implemented. In the end, our marketing and customer services teams implemented the following approach:

  • Developed a questionnaire to confirm the user’s mobile phone model
  • Screened users individually
  • Collected feedback in batches to be passed to the developers
  • Notified the users of all updates related to their phone requirements
  • Re-tested and reevaluated the same user batches for corrections

Learnings

While each product development cycle will be unique, there are a few big takeaways from our experience that will likely apply to other companies trying to develop, test, and launch a product remotely.

Expect delays and extend your timeline

Even with teams becoming more proficient at working remote, your company should expect unforeseen delays both internally and externally. We saw this in everything from doing our own market research to finding a suitable hormone partner and adding in plenty of buffers will save you a lot of stress.

By far the biggest delay we faced was product testing and the communication surrounding it – regardless of whether you’re launching a new piece of software or hardware, taking the time to document how testing should work will be invaluable. Make sure to include how feedback will be passed along, how updates will be conveyed to users, and how the entire process will be tracked and monitored.

Determine your communication processes ahead of time

One of the biggest things we did right was determining how communication would take place over the entire process. Our advice is to create centralized docs, refer to them every time you meet, and prioritize email and chat before coordinating virtual meetings.

As evidenced by our product testing delays, there is a fine line between clarity, speed, and depth. Our mistake was treating this structure as more rigid than it should have been, and opting for more in-person calls while refining the product would have helped.

These challenges are not unique to COVID

Despite everything you read above, we actually had an advantage going into this when compared to other companies: we were familiar with working across global teams. Mira has always been an international company and every one of our products has been launched with the help of teams that never set foot in the same room.

No matter if your company is dispersed, global, or simply planning to adopt some form of remote work going forward, you will face versions of these challenges no matter how prepared you are.

Give remote work a trial run

Hindsight is always 20/20 but the underlying cause of many of our struggles was that most of our team hadn’t worked remote before. While this is to be expected in a lot of industries, you can save a lot of ‘getting up to speed’ time and effort by letting staff dip their toes in the remote water before they actually have to. Even a few days a month can save a ton of time as people try to figure out the best ways to coordinate and communicate remotely.