Good product isn’t enough
We’re no longer in a world where technology alone is the answer.
Mat Balez, Rachel Lin, & Bay Gross — Product at Cityblock Health
In our years of building product, we’ve been fortunate enough to work with world-class engineers, product designers, and data scientists to bring to life innovation in web security, mobile mapping, ridesharing, meal delivery, ad tech, search personalization, collaborative productivity tools, voice user experience, education technology, and more. And now we’ve found our way to Cityblock Health, where building product looks, well, different. At Cityblock, we’re going beyond good product — and doing so hand-in-hand with clinicians and community members to bring better care to where it’s needed most.
Through many ship cycles, involving our fair share of successes and failures, we’ve seen firsthand that building good product must be ruthlessly focused on bringing to life well-designed software that meets core user needs and aligns with business goals, no matter the industry.
While “good product” in each context shares the same baseline principles, what it actually looks like varies widely. The digital products we’re developing at Cityblock — anchored by Commons, our care delivery platform — connect our members, our care model, and the community. Our products bind together a complex system of distributed community-based care teams, care delivery workflows, messy data feeds, and multimodal member interactions to ultimately improve the health of our members and their neighborhoods. These tools are designed to help drive a step-function change in operational efficiency, enabling us to learn and iterate based on system performance all the while. Unlike much of the software we’ve built in previous lives, it’s a lot more difficult, and in equal measure gratifying, than “shipping an app” that people like to use.
Since healthcare is a bit of a foreign world to most product folks that haven’t stepped outside of tech, it’s worth pulling back the curtain a little bit on what we’re building, and why we keep swimming, sometimes against the current, to do so.
When we set out to build Commons, we knew it had to drive action in the real world, helping our care teams deliver better care to every Cityblock member. It’s what will ultimately drive our success or failure: enabling our field-based care teams to focus on performing the most important task at any given moment while seeking to push all the noise into automation and back-end workflows wherever possible.
We launched Commons in summer 2018, at the same time opening our first Neighborhood Hub in Crown Heights, Brooklyn. Over the course of the preceding year, we diligently built an MVP with a relatively large product footprint (as so many operational workflows need to be supported) but that was still as “minimal” as it could be. Having been live now for over six months, a few substantive features have stood out as particularly impactful for our care operations in the field:
- Measurable member & care team communications. We’ve built product infrastructure for our care teams to chat in real time and to seamlessly communicate with Cityblock members and their families via voice or text message. Each of these interactions is measurable, so we can continuously assess what is working best in care team-to-member engagement, and where we can improve. This integrated measurability provides important visibility to help us identify pain points in responsiveness, and to identify and focus on relationships that need more attention. It also allows us to capture substantive context from these interactions and parse these data to drive automated action. As important as measurability is for our operations, the biggest takeaway has been creating a feeling of reliable connectivity for our members, a sense that there is always someone they can reach out to when they need it most.
- Task-driven personalized care plans. Delivering integrated medical, behavioral health, and social care requires managing complex and high-scale logistics for each member and community we serve. The best way to manage and improve such operations? Fine-tuned measurement through task management. As such, the entire care plan for each of our members (their “Member Action Plan” or MAP) is defined in Commons as a set of organized tasks that are rich, interactive objects — used to house discussion and to enable us to audit and communicate ownership for every task (large and small) that we are working on with each member. Because the details matter, we’ve created our own custom taxonomy of top-level “concerns” that span all possible areas of health and social needs in language that is easily understood and accessible for our members and care teams.
- Multi-source, data-driven decision support. We have experts at Cityblock across primary care, behavioral health, substance use, social work, palliative care, public health, and other specialties. We also ingest multiple data feeds spanning electronic health records, insurance claims, health information exchanges, and pharmacy, while also collecting data on the behavioral and social factors that affect members’ health (a.k.a social determinants of health, or “SDoH”), assembled in Commons via screening tools, our own structured assessments, and publicly available community data. Leveraging both our clinical intelligence and this massive data set, we can drive better care in the field through custom-built decision-support capability woven into our infrastructure and the Commons user experience. This means we can conditionally suggest actions via tasks that populate each member’s individualized plan of care (i.e., the MAP) based on their specific needs and goals. And the fact that these suggestions are constantly recalculated dynamically behind the scenes, based on new data as it arrives, helps us keep our members’ MAPs up-to-date over time.
- Real-time care transitions. When one of our members enters the hospital system, we have at least two time-sensitive opportunities: (1) to quickly deploy a care team member to the facility to positively impact the acute care experience, help minimize length of stay, and ultimately help reduce the risk of avoidable readmission, and (2) engage with members when they are most amenable to changing health behaviors. To that end, we ingest live data from multiple Health Information Exchanges (HIEs) to maximize coverage and capture of inbound clinical event notifications triggered on admits and discharges from participating facilities. Commons then automatically populates a global transitions census and routes the notification in real-time to the member’s care team — simultaneously initiating a digital chat session for real-time collaboration. Providing space for such event-driven, real-time collaboration is critical in practice: it allows care teams to virtually come together to decide the most appropriate and meaningful next action to take for the member.
We didn’t get everything right out of the gates. Some important workflows, like those geared around actioning an outreach list in optimal order, were not well-incorporated into the product on day one. But in this case, a cross-functional team dove in, assessed the gap and quickly iterated to build a great product solution that now helps to drive member outreach and engagement results that are already well above those seen elsewhere in healthcare.
There were plenty of other things we missed — UX friction points that were not obvious prior to being live in the field, content gaps in the questions we ask and interventions we deploy, some IT reliability issues that had many overlapping root causes — but it’s all stuff we can now fix and are fixing. Since we are up and running, and collecting the necessary data from members and care teams, we can improve the product every day, with every release, in both visible and invisible ways.
This is merely a starting point. There is so much more to build: Experiences designed exclusively for members and families. Deeper integrations for community providers. More sophisticated machine learning that leverages our longitudinal, SDoH-informed datasets to improve the fidelity of our decision-support capabilities. Tighter integration with EHRs. Voice input. Real-time monitoring. Automated chat interactions. Endless good product to build in the coming months and years.
There’s a crucial caveat to all of this: supporting a live healthcare operation, as we do at Cityblock, means that building and shipping good product is simply not enough. All of the product we describe above, and everything we will continue to build, would not amount to anything if we did not have the right philosophy and approach for building and shipping software.
More than any industry in which we’ve worked previously, healthcare demands a deep integration with the stakeholders with whom, and for whom, we’re building — reflective of the very integrated nature of the product and operations that it powers. In subtle and important ways, the human side of the build process is integral to the product itself. In other words, the meta-product that is the process through which we build good clinically-informed product here is the product.
If this is all a little abstract, let us make it more concrete by sharing some of the lessons we’ve learned from building product this way over the past couple of years:
- Be humble. And brave. It takes a product team of engineers, PMs, and designers willing to begin from a point of massive knowledge asymmetry and quickly gain a deep understanding of a complex problem space in order to contribute meaningfully. To help get there, it takes a supportive environment of clinical experts to teach us every day. It’s only possible if we stay humble about what we don’t know as a means of learning what to build. (And it requires humble clinical partners, also willing to be pushed to operate very differently than in any past environment.) It also takes appropriate respect of the legacy systems and tools that have come before. While often reviled and dismissed, there are good reasons why things “are the way they are” and lessons to be derived even while challenging systems that need to change.
- Collaborate deeply. Adopting a learning posture in product development necessitates building deep relationships between tech and health experts to conceive of and develop every single product feature. We regularly bring together teams spanning engineering, design, PM, care delivery, and operations to start from problems, not solutions. We call our early exploratory meetings “Product/Clinical Jam Sessions” as they are as much about requirements gathering and brainstorming as they are about cross-team bonding. The culture of joint ownership across a diverse team spanning product and care delivery that has emerged is perhaps the most valuable result — it cements us as one integrated team building together.
- Can’t stop (won’t stop) at launch. Shipping product at Cityblock never ends at deploying code to production, as it often does at consumer startups where the aim is merely adoption. Successful product feature launches in our world — where day-to-day clinical operations and delivery depend on product predictability — require that we bring everyone impacted by every new feature or change up-to-speed before rollout. Good change management is crucial, as is putting in place the right accountability structures and measures for ongoing monitoring. These are not muscles well-exercised outside enterprise tech, so new processes and habits need to be learned.
- Be exceptionally responsive. With Community Health Partners and field-based care teams using Commons every day, we feel a high degree of responsibility to be available and responsive to product needs as they’re identified — our technology must never stand in the way of member care. To that end, we’ve set up communication forums — including weekly brainstorm sessions, engineers rotating through our Neighborhood Hub, and a #product-feedback real-time chat channel for reporting bugs and discussing feature suggestions with the whole product team — to enable tight integration of our teams, and allow people to share what they are seeing and close loops extremely quickly.
Nothing about these insights is fully solved — we are constantly refining how we do what we do. Many challenges remain a work in progress: How do we move an order of magnitude more product work through our team? What is the best way to structure all the feedback we get from the field for maximum learning? How do we know we are iterating in the direction of greatest impact every day? If you’re the type of person that wants to help answer such questions and wield your product skills (be they engineering, design or PM) for good, come build with us.
A parting reflection: From product-building friends in all areas of tech, we hear growing dissatisfaction with the things they’re building and how they’re being built — short-term thinking, vanity metrics, little yield to societal value, disconnection from the user. The antidote, we believe, is two-fold. First, choose to build in spaces where crafting good product actually yields transformative changes in human lives and giant social returns — even if those spaces on the surface of it are filled with intractable legacy complexity, like healthcare. Second, and most crucially, embrace the fact that in those most difficult spaces, the making of the product smashes us, as product builders, into new parts of the organization (like working in Neighborhood Hubs in Crown Heights) with new demands for how that product gets baked into the operations, and very DNA, of the company.
Building good product isn’t enough. Building good product for the right reasons and the right way might be.
