Leader Spotlight: Improving product development through documentation, with Mark Francis

---

Mark Francis is Chief Product Officer at Electronic Caregiver, a health technology company that manages healthcare protocols, chronic care, and emergency response. He started his career in the healthcare space and worked in business development and leadership for companies such as Age Wave, Health Hero Network, and Harrison Clinical Research. Before joining Electronic Caregiver, Mark held product leadership roles at Intel and Amazon Web Services for nearly 10 and three years, respectively.

In our conversation, Mark discusses the importance of stakeholders across all business groups embracing the need for documentation and transparency, and shares an instance when a lack of documentation stalled development for 20 weeks. He talks about his role in developing innovations at Electronic Caregiver, including building a virtual caregiver that integrates with a patient’s home and lifestyle preferences. Mark also highlights why blending product and innovation teams is essential to a business’ success, and shares an example where not doing so may have resulted in losing out on a $50 billion market segment opportunity.

---

‘Providing guardrails and getting out of their way’

You have an impressive background leading teams. How would you describe your leadership style?

My approach is being collaborative by teaching people, providing guardrails, and then getting out of their way to enable them to perform. I believe that the best thing to do is create a team of self-motivated builders and achievers who are so successful that I am no longer needed. It’s important to create a team of people with motivation, experience, and an appetite to improve and achieve. Give them everything they need to do this job, as well as for the betterment of their career.

The best thing to do is to support them from behind, but enable them to be the face of the product, both internally and in the market. If I’m able to do that and my team can develop strong products in a good cadence, I would consider that success.

I also love when we create opportunities for folks to move into leadership positions, either within or outside the organization. At the end of the day, we want to create shareholder value and take products out to the market, but we also want to grow our talent base. Then it’s our job to retain that talent.

Emphasizing the importance of documentation

In addition to leading teams, you’ve also helped build them from scratch. What’s your approach to putting together product teams, especially in the context of the innovative environment that you’re working in?

During my career, I went from policy to startups and pivoted from large companies all the way back to small ones. A lot of this was a purposeful choice of wanting to build out a skill set and learn what it takes to win in the marketplace. I bring that approach when I look at how to build and lead teams. A big part of this is to focus on diversity.

I am a first-generation American and value the different perspectives and experiences people bring to the table. When I was at Intel, I put together a team and I wanted as many people as possible to be represented — men, women, older individuals, younger individuals, and different ethnicities and races. I try to focus on building a team of builders because if we’re innovating, we’re creating something new and different. I want people who enjoy creating things and have a track record of achieving results.

I also look for people who are used to overcoming adversity. This is because most innovation doesn’t succeed, especially if you’re trying to do more than an adjacency. If you’re trying to do something more transformative, it often doesn’t go how you think it will. People who have the resiliency to say, “We thought there was something there, but there isn’t. Let’s pivot or take those learnings and apply them to another opportunity” end up driving the best outcomes.

When you bring people with different backgrounds together, how do you make sure everyone is aligned and moving in the same direction?

I lean heavily on product requirement documents, software development documents, design specs, and a resource and execution playbook. It’s easy to get a team of folks together who just want to go. We need to get everybody aligned through a discovery process, which then comes back to a documentation process. This is how we’ll know what a product requirement and market requirement document is, the software and hardware development plans, acceptance criteria, etc. These all have foundational importance to achieve product-market fit.

It’s actually good if these documents are more detailed than you think they need to be because that extra work upfront always pays dividends on the backend. Team members are then empowered to be set free and exercise their skill sets to the highest degree possible.

Some groups might be used to constant documentation, such as designers. How do you instill the importance of documentation for folks that it may not come as naturally to?

For us, it is very important that stakeholders across all business groups embrace the need for documentation and transparency. For technology groups and designers, it’s often natural. Designers often wireframe — they start documenting and sketching ideas and move to different degrees of fidelity. For other groups, particularly business ones, that’s not necessarily the case.

I’ve experienced a challenge where a business group was in a conversation with a customer, agreed to something, and told us to move forward with it without realizing the complexity of what they promised. This one customer was responsible for 60 percent of our revenue, which isn’t ideal because you never want to be that concentrated. They expressed a need to one of our customer account managers who agreed we could easily and quickly develop it and informed the product group.

The request was related to data capture, analysis, and reporting to create a specific report, but that report could be done in 15 different ways with 20 different components. There were questions like what data is required? Who has that data? How do we integrate this data into our backend? What is the intent of the report? What frequency and format?

None of that was talked about prior to commitment. Since this was an urgent request, the team started developing it. The account manager thought it was going to be a two-week effort; it actually took 20 weeks. It stalled the development of everything else because the whole team had to get pulled into delivering this simple report.

This was a painful but valuable lesson about not committing to anything prematurely and documenting everything. If you have a product development request, document it and specifically understand the request, utilization, requirements, and acceptance criteria. Then, have both companies sign off on this development request prior to beginning work.

After that incident, we had so much clarity in terms of what we were developing and what the customer needed that we ended up doubling our development cadence. The customer couldn’t always tell us what they needed, so we’d go through a deeper set of inquiries with them. Sometimes, that resulted in clarification and development, but a lot of the time, it turned out that it wasn’t something they needed from us — they could get it through other means.

Developing Addison the Virtual Caregiver

At Electronic Caregiver (ECG), you have a virtual healthcare avatar, Addison. Could you talk a bit about that and share how you determined which features and capabilities to include?

The company’s founder, Tony Dohrmann, started the company 14 years ago with the prediction that the future will be around connecting people at home — not just with security home controls, but with bringing health into the home as well. Right as that effort was happening, ECG got early access to the Alexa SDK. Tony saw that voice was a tremendous interface, but people don’t form a personal relationship just with voice. He wanted to bring a face and body personality to Alexa, which spawned the vision for Addison — an avatar that embodies the customer and their preferences.

With that vision, we started working on building and evaluating tools. We ended up settling on a platform called Unity. We worked with our designers to make the virtual caregiver and environment she operates in to be as realistic as possible, while not looking so real that it could be disturbing to people. We now have 14 different versions of Addison in the market; you can modify her gender, race, age, language, and environment.

We also do something called atmospheric mirroring. If it’s morning at your house, it’s morning in Addison’s house. If it’s raining outside, you’ll see that outside her windows. We want to create an intimate connection. Addison isn’t just your wellness coach, she’ll also ask how you are doing, encourage you to take your vitals, manage your medications, and do care routines.

Have there been any stumbling blocks with your target audience, such as older folks being a little uncomfortable with that level of technology?

We’ve found that people don’t want to compromise their independence or have intrusive monitoring. We’ve developed Addison so she can be as intense or light as you would like. That’s something we learned over time through things like focus groups. We have a two-year cohort of folks who are using Addison who we rely on for feedback. Or, if we’re developing a new feature, there are some senior housing providers in New Mexico that we turn to. We bring in 50 people and get their feedback on new features and functionality. We’re always doing surveys and assessments with our existing customer base as well.

Can you give an example of a feature that you originally thought was what people would want, but changed based on user feedback?

When we launched Addison, she was very scripted at certain times of the day. With medication, it’s fine to be on a specific schedule, but people wanted more freedom in terms of when certain things happened and the choice of whether or not to interact with Addison.

When we first launched, there was a narrow, 15-minute window to respond to Addison. We’d have a morning wake and check-in where she’d say what day it is and give a little trivia fact. That would be delivered at, say, 7:00, and by 7:15, if you didn’t respond, an alert would go out to a caregiver. People instead wanted a window of time because they might wake up late, for example. They wanted freedom. That was really good feedback for us, and we adjusted some of the features accordingly.

Blending innovation and product together

In many of your past roles, as well as your current one at Electronic Caregiver, there are so many different innovations happening. What’s your approach to promoting a culture of innovation within your team?

My approach is to step back and understand the business itself and the business unit you’re part of. What are the structures, goals, and priorities? It’s crucial to have a clear alignment between what the business and business unit are doing and what you’re looking to do as part of an innovation team. At the high level, you have to make sure you’re aligned with where the company as a whole is going.

A good example is when I was at Intel. I had a cool job as a venture lead; I was asked to identify market opportunities for emerging technologies and assemble a strategy and team to pursue the business. About 10 years ago, my team and I saw a convergence of wearable computing, machine learning, flexible displays, and low energy sensing. We put together a business case for Intel on “how to win in wearables.”

This was before the Apple Watch, Fitbit, etc. We’d start with iconic products, show what’s possible, and address hard technology problems. From there, we’d create the assets needed to be a platform so the industry as a whole could accelerate the growth of wearables.

We saw that the biggest hole in the market was that there was nothing purposely designed for women. Every smart wearable, whether it was for fitness or other purposes, was designed for men. So, we identified our persona as a 32-year-old fashionista woman who lived in San Francisco and decided to build her a wearable designed as a cuff bracelet. It brought up many technology challenges because of the shape and curvature, cellular connectivity, etc., but we felt those challenges were worth addressing.

As we worked on this project, the company got excited about it and the ownership of this initiative got transferred away from our innovation group to a team that was focused on developing wearable products. Our goal was to build a platform but that group wanted to build a series of iconic products. While this was exciting, it was challenging for Intel — the company was not comfortable building consumer products. They were best at creating ingredients and enabling platforms. As this dynamic unfolded, the company was impatient for results and decided to end-of-life the core CPU line, which was foundational for wearables.

It’s painful because now you see wearables as a $50 billion market segment. We were way ahead of everyone in the market, but we also needed to make sure our approach remained aligned with the DNA of the company. Since any new market takes time to develop, we needed to do more to protect the new venture from institutional impatience. This is not unique to Intel — it’s referred to as the innovator’s dilemma.

Lastly, some leaders view decision-making as their responsibility while others take a more collaborative approach. What is your approach to making decisions and getting consensus from your teams?

At my core, I’m not a “decision-making by committee” person because it’s time consuming and you don’t always get the best decisions that way. I want to offer an environment where everybody has a voice and folks can have a spirited debate about different options that are backed by facts and data. At Intel, one of our core principles was to disagree and commit. I believe in collaborative decision-making, but once that decision is made, if it’s different than you wanted, you can disagree but put everything you can behind supporting that decision anyway.

The other thing that stuck with me came from when I worked at Amazon. Jeff Bezos talked about two different types of decisions: one-way door and two-way door decisions.

Amazon found that over 90 percent of the decisions they make are in the two-way door bucket, where the consequences of getting the decision wrong are minor. It’s like a swinging door in the kitchen — make a decision, go through the door, and if it works, keep going. If not, come back through the door and make a different one. Less than 10 percent of decisions are one-way door decisions, which means it’s an effort to open the door, and once it closes, it’s closed behind you. You’ve made a costly commitment.

Personally, I try to push that decision-making down as deep into the company as possible and empower people to make decisions and support the ones they make. If it turns out that we need to go back through the other side of the two-way door, that’s OK. When we do that, it lights a fire within the team. When folks understand that they’re seriously empowered to do that, the velocity of what they do and the quality of the work skyrockets.