Facilitating collaboration and defining ownership to build better products within a complex product-development environment.
Datavant is building an enterprise SaaS product, so our business model is unlike that of consumer applications. How do we facilitate collaboration, define ownership and remain customer-obsessed given that we serve several highly differentiated groups of customers who use our products in radically different ways?
Broadly speaking, Datavant currently serves 4 different customer verticals:
- Life Sciences/Ecosystem/Public Sector (ie: pharmaceuticals and government)
- Payers (ie: insurance companies and Medicare/Medicaid)
- Providers (ie: hospitals and clinics, etc.)
- Attorneys and Life Insurance
Across those 4 verticals, we offer 3 core products:
- Privacy-Preserving Record Linkage (aka Tokenization)
- Release of Information
- Medical Record Retrieval
All of our products are built on the cornerstones of data privacy, security, and compliance, but some of these products exist in a landscape of de-identified data and some exist in a landscape of identified data. To complicate the scenario a little further, customers and products do not exist in a 1:1 relationship. Within each vertical are customers interested in more than one of our core products.
Given the complexity of our product:customer matrix, which exists within a rapidly growing business, and given that our business exists within a rapidly growing health tech ecosystem, how do we ensure that we:
- build products customers need,
- build high quality products that customers continue to want to use,
- have fun building products?
This last point is quite important and not necessarily a given unless we decide to prioritize it. We want the [Engineering-Product-Design] group to have fun, be happy, and be inspired by each other; happy teams lead to better business outcomes, and people are…happier.
The [EM-PM-PD] Group
The relationship between Engineering Manager (EM), Product Manager (PM) and Product Designer (PD) sits at the nexus of our product development. There’s a healthy and to-be-expected tension between these three areas as we move from techno-theater to viable products:
- “That idea sounds super cool…” (-EM)
- “…but no one will pay for it.” (-PM)
- “That idea sounds super cool…” (-PM)
- “…but we can never build it.” (-EM)
- “That idea sounds super cool…” (-PM)
- “…but what is the problem space we are solving for?” (-PD)
How do we keep this group and the associated Engineering Pods (Datavant’s term for the smallest size engineering team) working as impactfully as possible?
Cultivating ownership
One of Datavant’s core values is for Datvanters to “Operate Like Owners.” One interpretation of that could be to set up highly delineated roles, in which each owner exercises full decision-making rights:
This could work well for individuals with certain skill sets at certain stages of product development. An EM who is highly focused on the issues arising in the engineering domain might be very eager to take on difficult technical challenges with their Pod, and to figure out the most scalable solution that can be shipped as quickly as possible. They might be deeply focused on code quality and coaching their team to write better tests, design better systems, get faster at on-call, and become top-notch debuggers.
If an EM’s interests skew toward the Product domain, though, they might become interested in understanding how their Pod’s work impacts a specific business outcome. They might want to understand why X is priority #1 and not priority #2. They might even want to talk to customers to listen for nuance in how the customer describes their needs. If an EM’s interests skew toward the Design domain, they may want a deeper understanding of user research insights and the entire problem space in which a project sits. Such a set of interests could rupture the idea of ownership as defined by “clear lanes.”
Organisms, not lanes
Rather than determine fixed lanes as a means to cultivating ownership, we seek to set up the [EM-PM-PD] group as a singular organism. The more each person in the trifecta is able to empathize with the demands of the others’ domains, the better they will be able to figure out the right balance of decision making rights. Individual decision making rights still exist. The goal is not to establish a decision-by-committee system, but to clearly articulate the balance of decisions to be made.
The ultimate goal is for individuals to make engineering, product, and design decisions in parallel.
In consultation with their Pod, they can also then determine how to operate together. Is this particular PM an outstanding planner and highly detail oriented? Maybe they’ll own the sprint board. Is this PD particularly business minded? Maybe they’ll take over a pricing study. Does the group use a project management tool? Do they conduct standups? Do they write Product Requirements Documents (PRDs)? Do they communicate via Jira tickets and iterate quickly?
Again, the balance and form of each “organism” is also relative to the given stage of product development. During discovery, the PD might lead research while the PM observes and synthesizes. Inviting in an EM can dramatically shift the discussion if the EM has deep empathy with a technical user. Engineers embed certain assumptions about use cases in the technical architecture: the closer they are to the customers’ needs, the better our products and the better they scale. This works in the other direction for decisions about technical architecture: a PD with a holistic view of all the products can advise on how different products should interact together.
With all of this in mind, the group must determine the best operating model for their Pod to impact the business outcome they are working to impact at their given stage of product development.
The ultimate goal is for individuals to make engineering, product, and design decisions in parallel, as we believe this empowers the greatest sense of ownership within the managing organism and within the Pod.
Pod collaboration and accountability
As we mentioned above, our customer-product matrix does not exist in a clean 1:1 relationship. Sometimes multiple Pods need to build the same thing to meet the demands of different customer verticals; sometimes a Pod wants to build on top of a core component that a different Pod built.
How do we organize collaborative efforts between Pods? Another of Datavant’s core values is that “We Value Time as Our Most Prized Asset.” Whatever form collaboration takes between Pods, it should be one that facilitates moving quickly.
So:
- If there are two Pods working on similar products where collaborating could make both products better, then they should collaborate.
- On the other hand, if there are two Pods working on products that depend upon one another and one team is held accountable to deliver a business outcome but is blocked by another team, we should find ways to adjust ownership so that one Pod is not blocking the other (…or figure out how to collaborate differently…) as this scenario diminishes autonomy and ownership.
In the diagram on the left, both Pods can hit their business goal independently of the other Pod. If both Pods succeed while also encouraging a fluid exchange between them, then the end product will be better.
In the diagram on the right, neither Pod A nor Pod B is empowered to hit the business goal. Pod B might receive something from Pod A and sit on it, or Pod B might be unable to advance while waiting for something from Pod A. In this case it’s nonsensical to hold either Pod accountable for hitting the business outcome. Not only does this structure slow us down, it also destroys real ownership.
Two types of dependencies, two types of ownership
Whereas we want to eliminate blocking dependencies in Pod collaboration to encourage greater accountability and ownership, we want to encourage dependencies within the [EM-PM-PD] organism, even if it makes the process slower because it reinforces working with intentionality.
In the long run, this saves time by reducing the number of things that get built that do not hit the mark for customers.
It’s not just about products, it’s also about growth
Datavant has never been a static entity, and a third of our core values is to “Prioritize Growth Over Comfort.” As we continue to grow, our goal is to set up organizational structures and working paradigms that allow for the possibility of deep ownership, and which can thrive across team expansion. In tying these structural decisions to our core values, we think we are proposing a durable way of thinking about organizing that can flex according to the realities of business needs and the varied interests of the individual Datavanters working within these structures.
About the authors
Authored by Matt Vail and Nicholas DeMaison with input from Aneesh Kulkarni, Varun Lahoti, Gracie Chen, Annie Powers and Alicia Loewenthal.
Matt Vail is an engineering leader at Datavant. He has over 10 years of experience in designing and building software products, recruiting and leading engineering teams, serving as a board member and angel investing. Connect with Matt on LinkedIn.
Nicholas DeMaison writes for Datavant where he leads talent branding initiatives. Connect with Nick on LinkedIn.
We’re hiring remotely across teams. Check out our open positions.
.svg)
