Leader Spotlight: Structuring teams around two different user groups, with Espen Scheuer

---

Espen Scheuer is Head of Product, Patient and Developer Experiences at NexHealth, a patient experience platform. Early in his career, he gained experience in product management by interning at companies like Nomadic, Workday, and Madrona Venture Labs. Most recently, prior to joining NextHealth, Espen worked as a product manager at Microsoft.

In our conversation, Espen shares how NexHealth structures its product organization around its two key user groups: developers within healthcare companies and broader healthcare providers. He also discusses how the Shape Up methodology has transformed ways of working within NexHealth product management.

---

Building for two separate personas

Could you start by providing some background on what you’re working on at NexHealth?

Sure. At NexHealth, we describe our mission as accelerating innovation in health care, and we do that for two main audiences via our two core products. Our first product is a universal API that helps developers connect to electronic health record systems. As an easy analogy, you can think about this like Plaid or Stripe. Where Plaid and Stripe make it easy to process payments or connect to a bank account, NexHealth makes it easy to connect to electronic health record systems that providers use as their data source.

This means developers can build awesome, value-added applications on top of that data, such as online scheduling, patient communication, claim processing, and financial applications. Instead of going to all these health record systems directly and figuring out how to integrate them, they can work with NexHealth in a single universal interface.

Our second product is an application that we sell directly to providers on top of that infrastructure. To better understand this, imagine Venmo and Plaid were owned by the same company. This product is pretty broad in scope, and we describe it as a patient experience platform, which means we help with everything outside of the core clinical care. It has everything that the practice needs to keep its business running smoothly.

For our product team, this means that we serve two very different customer bases. We have developers who want to connect to electronic health record systems, and we have our providers who want us to use that data to make their lives better.

With two very different products, each serving a specific audience, how do you create a holistic approach to discovery?

My model for discovery is to use user research to build a mental model of the world, and then take that mental model and inform what we build for our customers. At NexHealth, this means that we have to expand the scope of our mental model. We not only understand how our providers go about their days, think about their businesses, and hope to grow and improve their practices, but also what problems their developers might be interested in solving and what data they need to solve those problems.

Our two audiences are actually more similar than you might think. Many of the things that we need are things the developers we’re serving also need, such as a reliable sync with customer data or accommodating different workflows.

From a product team perspective, we’re always thinking about those two different user groups. We structure our team around those two groups as well. We have PMs work exclusively on the developer side of the business and PMs who only work on the provider side of the business, just to constrain the amount of context and complexity that a single person has to keep in their head at one time. I’m fortunate to have really strong PMs on my team who think deeply about solving problems for their customers.

You talked about better understanding the needs of providers. To get that context, do you do provider site visits?

We love doing in-person visits. I think a lot about two categories of user research — active and passive. Often, we’ll do 10 user interviews about a specific feature while also absorbing passive research in the meantime. I also find it very important to have a constant touchpoint with customers. A lot of my calendar is spent in customer-facing conversations, and we want our customers to frequently talk to our product team as well. We’ll try to turn those into opportunities to ask them about things we may be working on.

It’s great to hear more about what they care about, what problems they have, and what else they’re facing. I want to make that as easy as possible for our team to do and reinforce.

Structuring product teams by product and user group

Can you say more about how you structure your product teams around two very different user groups?

Sure. We use a POD model and divide teams based on features. We have PMMs, designers, and teams focused on our developer product, developer portal, and API, our provider product, as well as internal tooling. We don’t have a ton of platform PMs in NexHealth today. That’s mostly engineering driven right now, but that’s something we’re always evaluating and looking for opportunities in.

In terms of how we work, we have taken the approach of forming tiger teams. We don’t have enough PMs to have multiple PM teams, but we often pull in engineers from different parts of the business when we’re working on a feature that crosses cuts and relies on deep health record system data. We’ve seen better outcomes by doing tiger teams compared to when we haven’t done them.

Overall, it’s important to be smart about when a functionality relies on a deep understanding of the health record system data as a whole. Right now, we have two PMs working collaboratively, where one is more involved with the data and the other is the definite owner. Even though we have some level of separation as our baseline, there’s always a time to make an exception. We recognize when it makes sense to form a tiger team and get more cross-functional.

Do you have an example of a time when solving for one user type came at the expense of another? How did you navigate the tradeoffs?

My framework for trade-offs is always impact and effort. How hard is it going to be to do something, and how much value are we going to get out of it? That’s where it gets nuanced. At NexHealth, we’re fortunate to have a really strong product vision. If it comes down to the API business wanting to build an integration off a piece of functionality that the SaaS business doesn’t explicitly need, that’s baked in. And because we have that trading baked in at the company level, it’s easier to make trade-offs between the two specific parts of our business.

Product is all about trade-offs, so we’re constantly weighting the order of execution and things we will and won’t do.

In terms of structuring your teams, do you often move people around? Or do they stay close to the features they’re initially assigned?

I really like giving people end-to-end project ownership. Before I managed a team, I got moved around a lot. We’ve had a ton of PMs get moved around as the needs of the business changed, and that’s totally fine. However, project to project, I find that having single product ownership through the entire initiative is the best way to go about it.

In product, you want to have the throughput of vision, decision-making, and accountability. It’s messy when things get switched mid-way, especially if you didn’t necessarily get a say in it because it got passed off to someone else. I’m big on end-to-end project ownership, but over time, I’m also comfortable moving people around as the interests and needs of the business change. That’s what I’ve found works.

The benefits of adopting the Shape Up methodology

You helped spearhead an organizational change that was meant to shift engineering design more toward product. What triggered that, and was there any friction early on?

This is one of those things that everyone wants to do. Everybody will say, “I want engineers who are more than just ticket pushers. I want them actively involved in the product process.” Especially with AI, we’ve seen a lot of roles being flattened or combined with other positions on the team. At NexHealth, everyone has a sense of accountability as a group, rather than assuming that the PM writes the story and the engineers just execute.

It’s very well understood that everyone wants more ownership. Then, the question becomes how to execute against that. We’ve seen a lot of improvement by tactically engaging engineering and designing a funnel. That’s been very well received. It’s then a matter of seeing the teams execute against it, getting feedback, and adjusting. We run versions of Basecamp’s Shape Up methodology where we have shaping meetings with engineering and design. We’re pretty early in this specific iteration, but everyone’s been excited about this change.

How has the Shape Up methodology helped increase efficiency and accountability on your team?

Before, we would often do product-to-design or product-to-engineering handoffs where the whole team was in the room. The hardest aspect of that is having precise expectations for your team on the outcome of those meetings. The Shape Up methodology has been really helpful for this because it’s a forcing function for engineers to come into these meetings with a purpose. They’re no longer just passively absorbing the information, instead they are speaking up and saying upfront how long they’re willing to spend on a project. That’s a core part of this Shape Up methodology.

The six-week timeline has also been great for the product development process. It’s led us to some really productive conversations where we’re cutting more scope upfront and just being really focused. That forcing function and timeboxing have been incredibly helpful in crystallizing the role of engineering in those early conversations.

When you were evaluating different methodologies, were there others that you considered in addition to the Shape Up methodology?

It was less about methodologies and more about wanting to solve the problem that engineering and design were left out of our process. We’re not super methodology heavy. In fact, Ryan Singer, the founder of Shape Up, talked about product-to-design handoff meetings recently on Lenny’s podcast. He mentioned having them earlier and more structured, and when I heard it, I was like, “Oh, this is the language I have been looking for to describe the version of the methodology I want.” It wasn’t so much that I evaluated a list of methodologies that came in, but that I discovered the right terminology and process for what I wanted to achieve.

What have the results been like so far by switching to this methodology, and what further changes do you anticipate as you think about the future of organizational strategy?

We’ve seen great results, specifically in terms of team sentiment and making higher-quality decisions. We’re faster and more willing to say, “Hey, we have to cut this,” or, “We’re doing this, let’s get it moving.”

Looking ahead, I’m sure there will be so many changes. If there are no changes, it’s like I’m probably not doing my job very well. I’m specifically keeping an eye on the POD model. I see that as something that people use to scale out how product teams have core product ownership. Also, we have one team that’s attached to a specific feature area of our business, and I’d love to replicate that model as we scale out.

The other thing I’m keeping an eye on is the combination of asynchronous and synchronous communication. We want to scale it to more connections. We try to have a written culture, but oftentimes, it’s most helpful to have in-office collaboration. That’s not realistic nowadays, so having more clearly documented checkpoints and things like that is on my radar.