This post is related to two previous ones that may be of interest. The first is a framework - Building AI-enabled Solutions - Why a Human-Centered Lens is Key and the second is a case study about a product which at the time was provisionally called Personalized Analytics. Just a year or two later a related product opportunity presented itself. While it was a great idea, it didn’t make sense as a standalone solution. It was eventually integrated into Personalized Analytics, in an effort to avoid further proliferation of sales-enabling tools, and provide a comprehensive set of insights and recommendations in one place.

In reference to my earlier framework, this post will focus mainly on Context and Algorithm Refinement.

Context of Use

Before I joined ZS, the company had invested in building a solution to assist sales reps in traversing through their territory more effectively. In principle, it sounded like a great idea. However at the time, the product organization was comprised exclusively of engineers; no user research or usability testing was conducted. The product was fully designed and built before anyone realized it was an expensive mistake.

As I mentioned in my previous post, the average age of pharma sales reps is 47, and as a result of their years of experience (and often long tenure in the same territory) they are deeply familiar with their territory and the physicians they call on. They keep notebooks to organize and track their activities, and they have driven their weekly routes many times. So the idea that a software provider would come in and offer a routing solution that completely disrupts how they’re working is ... misdirected at best.

The routing solution was eventually sunset without ever being piloted or sold. But, as a result of the work on Personalized Analytics, discussions resurfaced about enabling reps to move through their territories more effectively. And this time we did conduct user research.

We knew a lot going into this new product:

• A primary care rep might be expected to call on 8 to 12 doctors a day

• Reps have an established route that they follow for that particular week of the month

• With the right tools, they’ve done a little preparation for those physician interactions

As we dug deeper, however, we learned more about the challenges rep faced in achieving their call planning goals. As the day gets underway a doctor might cancel, or be at a different location, or unexpectedly be in surgery. Suddenly, what was initially an eight-call day turns into a five-call day, and the rep is now scrambling to find contacts in their territory that can allow them to meet their expectations in terms of productivity and ultimately revenue.

We realized the solution was not to tell them what to do, but to deeply understand their context and how they were navigating their day, and augment that. This provided a little lift that we eventually called Dynamic Targeting, a solution that would help them achieve their goals consistently rather than attempting to override their wealth of knowledge about their territory and the physicians in it.

Through dialogue with reps at a pilot customer, we learned how different it is to traverse an urban territory like Brooklyn compared to a rural territory like East Texas. We realized we would need input from the reps to understand how they move through their territory so we could augment it. The reps’ willingness to provide insights into their patterns of movement enabled us to envision, design, and build a solution to support them effectively.

Algorithm Refinement

Some of the most exciting work of my career so far was the work that the product User Experience team did with our data scientists. There were two major things that we worked on with the data scientists: (1) changing the timing and frequency of presenting new data into the solution, and (2) creating differentiated logic to serve up insights for urban and rural territories.

Data Ingestion

Pharmaceutical sales data is released five times a month. Weekly sales data is more timely but not as accurate, and the monthly data lags but is more complete. In the interest of ensuring the system remained engaging with fresh insights, our solution used the weekly data. At the outset, the solution received all of the data, generated insights for the week, and dumped them into the interface.

That resulted in exactly the behaviors you’d expect - reps would log in on Monday to review new insights, and then maybe log in on Tuesday to catch something they missed or needed to review. Insights for Friday clients were missed or forgotten because reps didn’t look at the solution again for the rest of the week.

We had a solution that was being used, but it wasn’t really integrated into their daily work. So the first big change we made was to introduce insights in relevant waves aligned with their schedules, so that the rep was encouraged to visit the solution every day.

Differentiated Logic for Urban and Rural Territories

The algorithm had a concept called the geographic center, and it made recommendations for where the rep should focus based on that geographic center. But that concept of “the center” didn’t take into account the differences between urban and rural territories or variations in movement through the territory by day of the week.

At the outset, all the recommendations for a rep in East Texas were geographically proximate to the center of East Texas, which might not be where the rep was going to spend their day. The rep might receive recommendations about physicians to visit, but they were not useful because the algorithm hadn’t taken the rep’s route for the day into account.

We needed to enable the rep to document how they moved through their territory so that the recommendations could in turn be more relevant for where they were on any given day. Rather than creating additional data entry requirements, integration with their existing calendar proved to be the easiest way to do that.

Together, we determined that the geographic center needed to be about the geographic center of the reps route instead - making it route- and user-centered rather than territory-centered. We began to explore the idea of an optimized center of value, which changed in accordance with the reps’ travel plans.

In Closing

By changing how data was ingested and presented and how recommendations were made, we were able to launch a significantly more successful solution, and ultimately an impactful pilot. The success of ZAIDYN Field Insights could not have been achieved if data science and UX hadn’t worked hand-in-hand.

Furthermore, our insights from user research, testing, and iteration were extraordinarily powerful when it came time to tell the story to pilot customers and ultimately in product marketing; we were able to tell compelling stories that we would not have been able to tell otherwise.

Finally, while each of the dimensions of my framework may not be critical for every single project, you can see the benefit of thinking through each of these dimensions as an area of potential collaboration to make solutions stronger through interdisciplinary collaboration.

Introduction

I’ve spent a significant part of my career enabling sales reps - as an operator, a UX researcher and then leader in large-scale software implementations and in software development, and eventually leading my own sales and delivery team. At SAP my teams and I worked with large enterprise, mid-market / territory-based, and tele-sales reps. At ZS we worked with all kinds of pharmaceutical reps, from primary care to specialty (like oncology) and medical device reps.

I’ve spent more than 20 years observing, researching, enabling, and building software for commercial organizations. It is my cumulative learnings about this user population that inform this post.

Enabling the B2B Sales Rep

When I was working at SAP, the average age of the large enterprise account executive (LE AE) was 47. Today, the average age of the pharma sales rep is also 47. These seasoned professionals have decades of experience, and in some cases they have been working in the same territory or account(s) for multiple decades. Any sales-enabling solution needs to be designed with that in mind; these reps want to do their jobs well, but given their tenure in role they will not take kindly to being told what to do by a piece of software.

Historically, ZS’ business was in sales enablement, and the firm worked in close collaboration with clients to inform how the pharma industry goes to market today. Each time a salesforce is being re/deployed for a new product, a similar process is followed - (1) equitable territories are defined (2) reps are aligned to those territories under the direction of a sales manager or regional director (3) call plans are developed for each sales rep based on historical data about the most impactful reach and frequency with each healthcare provider. And finally compensation plans are created and tracked based on the goals established. ZS has software and professional services to assist clients in all of these areas.

Reach is the number of unique individuals, and frequency is the average number of times an individual hears the message. Reach and frequency need to be balanced; exposing many more physicians to a message is important for new product launch, but high frequency is more likely to keep an in-market drug at top of mind for a prescribing physician.

It’s important to note that these efforts - usually conducted via statistical analysis - are balanced with the knowledge reps have of their territory and physicians they call on. There is a wealth of data available about physicians, their prescribing behavior, and how they respond to different live and digital touchpoints. But that data is notoriously hard to keep clean - doctors move, they die, they have offices in multiple territories. All that must be taken into account before the rep can plan their day, week, or month.

In software sales, a Customer Relationship Management (CRM) system enables reps to communicate their pipeline and deal progress to management. In pharma sales, reps are not selling directly but rather communicating to drive awareness and demands for the products “in their bag”. In this case, the CRM tracks reach and frequency but also regulatory compliance - reps have to document what they spoke about, and what materials they used (if any). The arrival of the iPad and mobile business intelligence solutions put new insights in the hands of the rep, enabling them to more easily recall prior conversations, view prescribing history, and plan their next interaction - and paving the way for new kinds of sales enablement.

Context of Use

Preparedness Best Practices Are Unrealistic

In the pharmaceutical industry, a typical primary care sales rep is expected to speak with 8-12 physicians per day, which requires 40-60 physician interactions per week. They also need time to prepare for those interactions.

As my team and I learned more about pharma reps and how they were working, it became clear that - even if their schedule was perfectly orchestrated each week - expectations of rep preparedness for those interactions was probably unrealistic. Reviewing data and preparing meaningful conversations with 40 physicians would require an additional full day of work each week.

Expectations for specialty reps (e.g. oncology) are somewhat different; reps might aim for the same number of calls, but have a shorter list of “high potential” doctors to focus on. The price of oncology products is more expensive, ensuring that live sales rep interactions are still a good investment. Those physician interactions are more complex, require depth of knowledge, and are typically handled by the most seasoned reps.

Pharma is a data rich industry, and analysts love having such a wealth of information at their disposal. But they don’t consider what it’s like for a rep in the car on wifi (or tethered to their phone) with 5 minutes to prep for her next call.

We had one client who designed a dashboard that gave reps access to the national sales data on their iPads. That may seem like wonderful transparency, but loading an entire national database while sitting in the physicians’ parking lot is an unmitigated disaster from a user experience perspective. The reps had to drill down from the national level down to their territory and into a physician view before they could review the data, seek insights, and figure out how to have a meaningful conversation with a physician about their prescribing habits or their patient population. The rep spent all the time that they had before their appointment just trying to get to the data to load, leaving them very little time for analysis and preparation.

In our observational research we saw all kinds of workarounds to these challenges - reps working through their planned calls at home and taking notes they could carry with them, or printing spreadsheets and carrying notebook with critical (and sensitive!) information, or putting screenshots into iPhoto to reference throughout the day.

Initially dubbed Personalized Analytics, our goal was to strip time and complexity away, and to provide the rep exactly the insights (not raw data, not analytics) that they needed in the rushed moments before a physician interaction.

Consumer Experiences Drive Enterprise Innovation

In 2016 I presented at ZS’s Impact Summit and I shared some of the big technical shifts that inspired our thinking about the art of the possible for new sales-enabling solutions.

In our technical teams, there was a lot of excitement about using chatbots and natural language processing (NLP) to enable the reps. In fact, we initially thought the new solution might be a conversational platform to deliver insights from existing repositories. Spoiler; we abandoned voice interaction for MVP after conducting user research.

When we started to shadow reps or speak to them about their needs, we were trying to figure out how to optimize their day as part of this solution, how to find efficiencies, get to targets sooner, have more effective conversations with the physicians in their territory. Sales reps spend a lot of idle time in the car and in waiting rooms, even when they have an appointment. To us, it seemed as though the time in the car could be used more efficiently.

However, as it turns out, most of reps are driving company cars, those cars that are insured by the companies they work for, and the insurance policies prohibit the use of the phone in the car. So what we thought would be a time-saving idea ended up being impossible. And using the idle time waiting in the doctor’s office proved impractical - they couldn’t use voice-to-text while surrounded by patients and office staff.

Even though natural language processing was an exciting feature from a technology perspective, it was deprioritized for MVP. Though today it is an integral part of the go-to-market story for the solution:

Users’ Mental Models

During our years of observational research with reps, we noted that they struggled to extract meaningful insights from all the data and analytics they received from headquarters.

We had a wealth of data, KPIs, and analytics collected over decades of consulting work. Our consulting experts pulled that information together and data engineering created a proprietary repository. Together, they created logical groupings of metrics.

Those “logical” groupings were an essential part of how the recommendations or next best action would appear in the interface. As we refined our prototype through usability testing, we found that the data model itself needed to change to reflect how the users thought about their work. I think one of our most important achievements in this product was proposing new groupings of insights in a way that resonated for our target audience.

I think it was unexpected for the engineering team to realize that the UX research could impact data engineering work, and our work together reinforced why such tight collaboration is necessary, especially in the early phases of building and iterating a product.

Algorithm Refinement

For this product, our insights about sales reps time constraints and context of use deeply informed the product concept. We weren’t explicitly involved in algorithm design, something we sought to rectify in our next project.

In Closing

As the solution came to life in code, we began to seek pilot customers, and I took point on presenting the solution to clients. It turned out that the tasks that we developed for usability testing were a strong foundation for demo scenarios:

We did not have a dedicated pre-sales function, and my deep understanding of the rationale for the design(s) enabled me to address client inquiries in real time.

This project was one of the most exciting projects of my career, because it built on a wealth of historical knowledge about reps, while still finding surprising new formative insights to shape product direction. It also led to some unexpected and rewarding collaborations with data engineering and product marketing.

Feedback from many rounds of usability testing confirmed we had imagined a product that was easy to use and met a real need. It is now in use by more than 100K sales reps worldwide.

Adoption is a Key Driver of ROI

The slide that anchors this post breaks adoption into three drivers which I have found to be at the root of most adoption issues I’ve been asked to address - Utility (“this is for me”), Usability (“this is easy to do”), and Behavior Change (“I see the value and I’m willing to change how I work”). In this post, I will address each of these areas of risk with the goal of making the concepts accessible to anyone who doesn’t necessarily have expertise in anthropology, design, or behavior change.

In my 20+ years building software, I haven’t built as many new solutions as you might expect - more often than not I’ve been asked to address concerns with a software solution that has failed to meet expectations in some way. Unfortunately, it’s often at the eleventh hour. Clients reach out because they are understandably worried about ROI, which can’t be achieved without adoption. I’ve observed other consultants recommend “aligned incentives” or “a strong launch and communications plan”, which are necessary but often missing the point; adoption is a human behavior problem.

Utility: “This Is For Me”

In the fields of Human-Computer Interaction (HCI) and User Experience (UX), utility and usability have specific meanings. Utility asks “does it do the right thing?”, while usability asks “can people do it easily?”. These distinctions are important when you’re trying to explain why solutions designed around new technologies don’t gain traction.

Utility is often the biggest blind spot for founders and product leaders. They recognize that the idea is good for them - for their workflow, their body, their level of expertise - but they unwittingly make assumptions that everyone else’s needs are the same. The elite athlete builds for other elite athletes, then discovers that the market opportunity is a set of time-starved weekend warriors with very different goals and constraints.

The good news is that, once uncovered, utility problems are imminently solvable. You do, however, need enough humility and curiosity to ask a few simple but uncomfortable questions:

• Where are we assuming “people like us” instead of understanding the people we actually serve?

• Whose life gets meaningfully better when this feature ships?

• What are they doing instead today, and why?

If you’re struggling with adoption, start by assuming your utility story may need work. “This is for me” is a feeling that emerges when people see their own needs and language reflected back at them.

Usability: “This Is Easy To Do”

Once something is genuinely useful, the next question is whether people can actually use it without frustration. In HCI terms, usability is about effectiveness, efficiency, and satisfaction in a particular context - can people accomplish their goals, with reasonable effort, and feel good afterwards?

Consider:

• At a macro level, how does your product fits into the flow of someone’s day relative to other tools, interruptions, handoffs, or the physical environment?

• At the micro level, do interaction design paradigms, patterns, defaults, and affordances smooth the path or create friction that adds up over time?

A product can be functionally rich and theoretically useful, but if it demands three extra steps in the middle of a call with a patient, or buries the one critical action in an obscure menu, people will quietly work around it. “Nice to look at” does not compensate for “difficult to use.”

A quick usability gut-check for your product:

• Are you clear on the core tasks the solution is designed to support?

• Can new users complete those tasks quickly and without guidance?

• Where do people hesitate, ask for help, or switch to alternative solutions?

• Have you observed them using your solution in a messy, real-life situation?

When “labels are understandable” and “interaction options are recognizable,” the solution is signaling respect for your users’ time and attention beyond learning your product.

Behavior Change: “I See the Value, and I’m Willing to Change”

The third circle on the slide is the one teams tend to underestimate, and it’s often the hardest. Behavior change cannot be an afterthought.

BJ Fogg’s Behavior Model is useful here - for a behavior to occur, people need Motivation, Ability, and a Prompt (Trigger) at the same moment. If motivation is high but ability is low, you get frustration and drop-off. If ability is high but motivation is low, you get polite compliance at best. If you never design thoughtful triggers, people simply forget to engage.

A lot of enterprise change management quietly assumes that communication plus training results in behavior change - update the incentives, send the email, run the training, and call it done. In reality, employees may have no choice but to log into the new CRM, yet still cling to old notebooks, side spreadsheets, and backchannel messaging because the system doesn’t align with how they actually work.

In healthtech, patients cannot be coerced into new habits - you only get the behavior changes that you’ve genuinely supported.

Imagine a patient starting a GLP‑1 medication and being told to “eat more protein” for best results. On paper, the behavior is simple - increase protein intake. In reality:

• Do they know what counts as protein?

• Can they afford healthy high-protein foods on their budget?

• Do they have energy and kitchen access?

• Do they have the time and the knowledge to prepare it?

• What if they’re vegetarian, or have conflicting cultural / religious practices?

They may be highly motivated to improve their health, but a cascade of ability barriers gets in the way - knowledge, resources, skills, environment, identity. A reminder notification or “nudging” message doesn’t fix that on its own; without addressing ability, triggers alone won’t drive behavior change.

This is also where ethics show up. There is a fine line between nudging and manipulation, particularly when people are vulnerable, tired, or scared. Designing for behavior change carries a responsibility; be thoughtful.

The Three-Legged Stool of Adoption

Utility, usability, and behavior change are not three independent checkboxes, they’re more like three legs of a stool - remove one, and the whole thing tips over.

• With strong utility but poor usability, people want what you offer, but using it feels so frustrating that they delay, avoid, or delegate it.

• With strong usability but weak utility, people can ease through your interface, but it doesn’t solve an important problem, so they don’t come back.

• With strong utility and usability but no behavior-change support, you get a spike of interest at launch, then usage quietly deteriorates as old habits reassert themselves.

The slide’s plus sign between the circles is important - adoption happens when users can say “this is for me,” “this is easy to do,” and “I see enough value to change how I work today.” Underneath that plus sign is an understanding people’s contexts, constraints, power dynamics, and motivations - things that result in sustained impact.

If you want to use your adoption issues as a diagnostic, you might start with a quick self-assessment:

• Where do we hear “this isn’t really for people like me”? (Utility)

• Where do we hear “I know it’s better, but it’s just too much work right now”? (Usability)

• Where do we hear “I tried it for a bit, then life got in the way”? (Behavior change)

The patterns in those complaints are telling you which leg of the stool needs reinforcement first.

Practical Next Steps for Founders and Product Teams

You don’t need a massive transformation program to start benefiting from this framework. A few focused moves can shift both your roadmap and your adoption curve.

1. Run a utility interview sprint

Talk to 5–10 current or prospective users about one core job your product claims to help with. Ask:

• “Walk me through how you handle this today, step by step.”

• “Where is it painful, and where does it actually work fine?”

• “If my product disappeared tomorrow, what would you miss, if anything?”

Look for places where real friction exists, and your solution can offer a compelling alternative.

2. Observe real-world usability

Schedule short, informal sessions where you watch people use your product in their actual environment. No pitch, no slides, just:

• “Show me how you’d do [task] right now.” Note moments of confusion, workarounds, or extra steps. Fix major sources of friction before adding new features.

3. Map one behavior using BJ Fogg’s model

Pick a single behavior you care about (logging meals, updating opportunities, reviewing lab results). For that behavior, write down:

• Motivation: Why would this person care enough to do it regularly?

• Ability: What makes it hard - time, knowledge, money, emotional energy, environment?

• Trigger: When and where in their existing routine would a prompt feel timely and helpful?

Design at least one change that lowers an ability barrier and one better, more contextual prompt (trigger).

4. Check the ethics of your “nudges”

For any tactic, consider that sustainable adoption and trust go hand in hand; without trust, no long term relationship will develop. Don’t lose sight of the fact that achieving greater Lifetime Value (LTV) with existing customers is more cost-effective than acquiring new ones.

Ultimately, my goal with this post was to provide a practical approach for ensuring your product will meet the real needs of users, ultimately delivering ROI on your technology investment(s). What adoption challenges are you seeing right now? Does this framework resonate? Let me know in the comments.

Throughout my career I’ve been told to “bury the Anthropology” by coaches and recruiters alike. “It’s confusing,” they said, “it’s a liability” or “it’s a distraction”. For the first time yesterday, an LLM said “keep it - it’s a differentiator”. I don’t need validation from an LLM, but after more than 20 years I still find myself surprised by how industry folks respond to my background.

For technology leaders and founders, a perspective on people is something you want in the room every step of the way. Anthropology – and human-centered design more broadly – ensures the product lifecycle centers around lived experiences instead of internal assumptions.

Why understanding people belongs at the start

If you build software without a deep understanding of human behavior, you end up paying for it later in expensive rework; would you prefer to spend $1 to fix a mockup or $100 to fix the code? The decision seems obvious to me. In addition to costly engineering rework, solutions designed without that human-centered perspective result in high support costs, low adoption, and eventually customer churn. The reason those solutions succeed or fail is bigger than just features and roadmaps. Leaders should be asking themselves “where in our lifecycle are we making assumptions about people and their behaviors, and who can help us unpack those assumptions?”.

Engaging with people across the product lifecycle

Help Desk. Early in my career, I worked in technical support answering up to seventy calls a day, I walked people through confusing software, failed updates, frozen screens, and yes, system reboots that resolved roughly half their problems. In my work I heard the same things over and over again - confusing workflows, unclear error messages, missing guardrails, poorly timed updates. So many of the of “technical issues” I fielded were actually interaction design issues, expectation issues, or training issues – all human problems.

Sales Operations. After moving from IT to Sales Operations, I conducted my first ethnographic research project, observing sales reps navigating complex enterprise solutions. It quickly became clear to me that these commercial systems were designed to meet management reporting needs, with little consideration for the sales rep and what they needed to manage a customer relationship. After shadowing sales people, I translated my observations into recommendations for interfaces and workflows that reduced friction and enabled the reps to focus on their customers.

Product Innovation. Anthropology eventually brought me to product innovation and UX leadership, and I became responsible for educating executives and engineers about our findings and their implications for software development. For executives, this meant highlighting the gaps between their assumptions and our observations. For engineers, it meant translating our findings – a plethora of systems, limited attention, habitual behaviors, personal preferences – into requirements and designs grounded in reality rather than assumptions.

Data Science. Most recently I’ve been working at the intersection of UX and data science, helping teams design algorithms that are aligned with how people actually think, decide, and work. Our work has informed the contents and presentation of a newsfeed, which AI-generated recommendations to prioritize, how metrics are explained, and even the cadence of data pushes into the interface.

Post-Sales Functions. Even after a product ships, understanding people remains central. Training programs only work when they respect cognitive load and time constraints. Professional services succeed when they acknowledge power dynamics and not just “best practices.” And customer communities – both in B2B SaaS and in healthtech – can make or break a business. When designed with empathy and real incentives, communities drive adoption, footprint expansion, and retention, because they facilitate learning from peers, build identity around your product, and create a feeling of being seen by the company behind it.

Practical implications

If you are a founder or you play a leadership role in product or technology company, consider the following:

• Bring human-centered perspectives in to inform early innovations and product-market fit, not as a last-ditch effort once a product fails to meet expectations. This is not the work of a product manager, but of a UX practitioner with research expertise.

• Treat help desks, sales teams, and customer communities as continuous sources of customer insight. Those cross-functional relationships hold a wealth of insight.

• Seek human-centered insights throughout the product lifecycle and the customer journey. Your customers will thank you with their loyalty and ongoing investment in your work.

Ultimately, the “bury your PhD” advice shows a lack of understanding of how compelling software is imagined, designed, and built. The urgent need in technology is more leaders who recognize that understanding people is central to a successful software business.

Following our interaction he sent me this jazzy summary, along with the video below. So fun! I'm hoping to explore the use of his tech stack in my own work going forward - in the meantime, enjoy!

Meet Natalie Hanson.

If you ever wondered what happens when anthropology meets high-stakes business, let me introduce you to Natalie. Our paths first crossed years ago, back when she and a few fearless executives were rolling up their sleeves to lay down the foundation for a knowledge management competency center—in a global software company with 20,000 employees. Huge groundwork, and it was done with integrity and vision I still admire today.

Fast forward to our recent catchup, and it’s clear Natalie’s “build-it-from-scratch” spirit never took a coffee break. From steering engineering teams and scaling organizations from zero to 300 people (not a typo) to pioneering new paradigms in women’s health - she’s made a habit of leaving legacies, not just LinkedIn endorsements. Her North Star? It’s about building more than a name, it’s building positive change that lasts, especially in healthcare and equity. That connection to purpose resonates deeply with me; both of us have led diverse, global teams, harnessed tech for impact, and still believe the best work is human work. 🌍

What struck me most was her genuine curiosity, not just about what I do now, but why I left the corporate comfort zone to chase entrepreneurial challenges. Her words were simple and powerful: “You’re ready for the shift when you feel it. Apparently, your time is now.” It was a friendly nudge and a vote of confidence from someone who has transformed pivots into a superpower. 💡

Natalie proves that integrating social science, tech, and bold leadership isn’t just innovative, it’s necessary. If you’re interested in impact, reinvention, or stories that outlast titles, connect with her. Trust me: she’s just getting started.

---

Who should be next❓Tag someone.
What is #TagTalkTribe❓https://lnkd.in/dg7Sc3nN
#TagTalkTribe #MeetNatalie #Legacy

My former team and I built our first AI-enabled solution in 2017, and in this post I want to share a few lessons we learned - especially regarding the role a human-centered perspective can play in shaping software solutions with meaningful AI features. After more than two decades of living, studying, and writing about interdisciplinary collaboration, I believe that in this era of AI, collaboration is as important as ever.

In the coming weeks, I intend to write posts that delve into individual project details, but today I want to offer an initial framework - one I hope will be useful to anyone staffing, guiding, or leading product teams. My goal is to provide practical advice instead of theoretical abstractions. I hope you'll find it of value!

Who should read this?

• Founders & heads of product - Especially those trying to build the best possible solution and assemble the right talent to solve challenging problems. Many may not realize the true benefits of this kind of collaboration.

• Data scientists - If you haven’t worked closely with social scientists or designers before, you might be surprised by what cross-disciplinary collaboration can offer.

• UX professionals - If you’re wondering what the rapid rise of AI means for your career and professional practice, this is for you.

Some of these points are relevant to broader LLM experiences, but here I’m focused on solutions designed to drive real-world behavior change, where, I argue, human-centered practitioners and data scientists must collaborate to achieve the best results.

Context is Almost Always Bigger than the Context Window

When we design new solutions, we can't assume users are always sitting in front of a desktop with a keyboard and mouse. They might be on a mobile device, on the go, juggling a weak wifi connection, or rushing to an appointment. We have to consider what they’re trying to do, where they are, the tools they have at their disposal, and potentially, their urgency.

The context in which a solution is used is almost always larger than the technical context window. This wider context relates to user intent, and it should be a key factor in thoughtful solution design.

Chatbot Personality and Conversational Design

There’s been active debate about whether ChatGPT is too positive - sometimes verging on sycophantic. UX researchers I've spoken to have observed that ChatGPT seems to surface positive outcomes from research data, but it often requires explicit pressure to highlight negatives. This remains a model-level challenge that should be addressed if AI is going to credibly solve business problems.

For business solutions, a chatbot should reflect the brand through politeness, tone, word choice, and reading level. These qualities matter, because the chatbot is a reflection of the business and the brand.

Experts in fields like anthropology, sociology, and HCI (human-computer interaction) have studied conversational design for decades. There’s no need to reinvent the wheel - we should learn from this deep body of knowledge when crafting computer-mediated interactions.

The Data Model and Users’ Mental Model

Building AI solutions usually involves data engineers or scientists thinking about the ontology and data model. Ontologies define meaning and relationships; the data model determines how data is structured. Similarly, UX professionals describe users’ thinking, motivation, and context to inform product strategy, and these can be represented in a variety of ways, including a UX artifact called mental models. Well designed, human-centered products consider both the underlying data and the users' mental models.

In future posts, I’ll share detailed examples of how this plays out, but the key idea is this - data in an app must be organized in meaningful categories so any returned results are actionable for the end user. Legacy software like Veeva (CRM) exemplifies pitfalls; rather than providing a unified view of a physician, reps must consult separate tables for details, prescribing behaviors, call history, sampling, and more. The experience is organized around the data model, not how sales reps actually work.

To build better solutions today, data scientists and UX professionals need to work together. Data scientists bring deep understanding of the data structure and relationships; UX professionals know how users frame problems and which vocabulary is natural to them. Together, these perspectives shape interface features, from navigation and menus to the way results are represented on screen.

When prompts and the user’s mental model align, ease-of-use improves, and users get the answers they need, faster.

Algorithm Design

Some might argue that algorithm design is exclusively the responsibility of the data scientists. Yet, if an algorithm is designed 'nudge' human behavior (which they often are), the combined team has to understand:

• What are we nudging users toward? Understand the journey, happy paths, and pitfalls.

• What do users hope to accomplish? Clarify user intention.

• Which nudge works, and when? Analyze human rationale to design effective interventions.

Algorithms shape what appears in the interface, how, and when. We must understand both the underlying data and the individual receiving the nudges. It's at the intersection of these two that we create impactful outcomes that actually drive behavior change.

Some of these points are relevant to broader LLM experiences, but today I’m focused on solutions designed to drive real-world behavior change - where human-centered practitioners and data scientists collaborate for the best results.

Further reading

• Managing chatbot personalities isn’t just for software solutions - Claude’s creators confront this challenge, too.

Big Technology

How Anthropic Builds Claude’s Personality

Every AI bot’s personality is the product of intentional decisions made within AI research houses, often behind closed doors. We typically only see glimpses of those decisions when things go awry, like in the cases of “white-genocide” Grok or “sycophant” ChatGPT…

Read more

a year ago · 25 likes · Alex Kantrowitz

• An insightful look at training Claude to match Every’s editorial tone: Teaching Claude Every’s standards—and what the editor learned

• Indi Young’s Mental Models: Aligning Design Strategy with Human Behavior is an excellent resource. There’s a helpful summary here: Book summary

• In healthcare, UX almost always incorporates behavior change design. Irrational Labs defines it as “using behavioral science insights to inform design decisions,” drawing broadly from behavioral economics to cognitive psychology and more. Learn more in this series by Samuell Salzer. Including experts in this field strengthens outcomes well beyond what UX generalists alone can deliver.

• Read Aakash Gupta's interview with Teresa Torres, especially the section on How To Do Discovery for AI Features.

What do you recommend?

If you’ve come across compelling, practical work on interdisciplinary teams in AI - especially studies, articles, or stories from real projects (not just theory) - I’d love your suggestions. Please share them in the comments.

When I wrote about my measurement framework last week, I reflected on the need to bring value to our business endeavors in concrete, measurable terms. A recent article about customer success metrics challenged me to revisit my initial thinking.

Most customer success metrics - like Customer Satisfaction (CSAT), Annual Recurring Revenue (ARR), or Churn Rate - are well known but operator-centric. Even CSAT (which seems focused on the customer) is really just the customer’s satisfaction with us. That’s useful, but it’s only part of the picture.

Metrics Through a Different Lens

Lynn Hunsaker’s recent article Executives’ Guide to Customer Experience Value Metrics points out that most metrics, even in customer-centric organizations, reflect how we’re doing, not how the customer is doing.

At the end of her framework, Hunsaker includes four moments that measure experience. While valuable, they are not true business outcomes:

It’s not enough to track our business performance or even customer impressions. What about measuring the real, tangible impact we have on our clients?

Reflecting on her work, I realized my own framework needed a shift.

Outcomes, Not Just Activities

Let's take a fertility clinic as an example. It’s typical to measure revenue-generating activities such as hormone levels measured, IVF procedures completed, and so on; it makes sense since those are services the clinic delivers and gets paid for. But for the patient, what matters is the actual outcome - a viable pregnancy.

Volume and productivity metrics risk being the "Musk Metrics" I described in my post last week - they drive revenue but are not necessarily a predictor of future success. In the long run, success comes from delivering outcomes that have genuine value in the customer’s life or business, not just our near-term bottom line.

Measuring Real Impact

The metrics of long-term business health that investors pay attention to - customer retention rates, revenue growth / predictable cash flow, and customer lifetime value - are a reflection of success that you have helped your customer or patient achieve through your product or service. In the end, what's going to keep your customer with you is if you're bringing value to their business or their lives in some way. And ideally, that is what you should be measuring.

—

I'd love to hear your reflections on this topic - what do you think of the revised framework? What are you measuring, and how does it reflect your customers’ real success? What challenges do you anticipate in measuring your customers' or patients' outcomes, and not just your own?

That quickly led me to another realization: very few people in UX actually understood the businesses they were trying to change - and that was just as problematic. Without understanding the business, it’s impossible to identify and drive meaningful change in its metrics.

Metrics that Matter

As part of a keynote I gave in 2018, I put together this slide to spark a conversation within the UX community on how we hold ourselves accountable to the businesses we serve.

The talk track went something like this:

• At the bottom of the grid are classic IT metrics. These often struggle to get the attention of the business because they’re technical - think number of concurrent users, number of logins, server uptime. Metrics like these are useful for infrastructure capacity planning, but these “vanity” metrics are rarely useful for business decision-making.

• UX has its own version of this problem. We collect metrics that are deeply meaningful to us - like the SUS score (a measure of customer satisfaction) - but business leaders don’t know what to do with them. By contrast, they’ll act on something like NPS because they understand its connection to loyalty and revenue.

• And then, at the top of the ladder, we find the real reason we show up to work every day - business outcomes. Metrics like customer retention, annual recurring revenue (ARR), cost of customer acquisition (CAC), and customer satisfaction (CSAT).

The structure of the slide was deliberate. All of our efforts should ladder up to business outcomes. If they don’t, we’re framing data in ways that only make sense to us, and not in ways that are useful or actionable to the business.

The biggest risk for functional leaders? Hiring talent that isn’t invested in understanding the business. Because it doesn’t matter if you create a beautiful algorithm or a beautiful interface - if you don’t understand the business intent, you’re unlikely to create a solution that drives lasting impact.

Elon Declares an Early Victory

I was prompted to revisit this recently because of a tweet by Elon Musk that Guy Allen reposted on LinkedIn.

Musk was claiming victory in the AI model race based purely on the volume of new releases, and I couldn’t help but ask: what’s worse than vanity metrics? The answer, in this new AI world, might be equating volume with success.

So I (temporarily) added a new category to my metrics slide - one step lower than vanity metrics: Musk Metrics.

“Musk Metrics” celebrate activity (like model releases) as if it were impact, which is like saying water is wet.

More Code Is Not Better

Soon after I saw Musk’s claim, I came across a study by Faros AI, summarized by Mallun Yen on LinkedIn.

The study reviewed the work of 1,255 teams and more than 10,000 developers using AI coding assistants. At first, the numbers look impressive:

• +21% tasks completed

• +98% pull requests (formal request for code changes) merged

But the story doesn’t end there:

• +9.1% more bugs created per developer

• +154% increase in pull request size

• +91% longer review times

The most important finding was at the organizational level: AI coding tools had weak or nonexistent correlations with actual delivery improvements.

Why? Because while individual coding tasks may be faster, organizational bottlenecks remain. As the report succinctly put it:

“Coding may be faster. Delivery is not—yet.”

In short, as Yen so aptly summarized -"More code is not better."

The Bigger Lesson

Whether we’re talking UX, IT, or AI-assisted engineering, the pattern is the same - metrics that focus inward are not enough. The only metrics that matter are those connected to business outcomes.

Because no matter what your craft is - whether design, data science, or engineering - we are all working in service of business outcomes, and along with that come metrics that define real change and impact.

What’s Next

I’ll be revising my original “Metrics that Matter” framework this week based on other news I've been reading. I’ll share more on that evolution in my next post - stay tuned.

In the meantime, what's your experience with measuring real business impact (or falling into the "vanity metrics" trap)? Share your story in the comments - I'd love to hear your war stories!

Get the First 5% Right

In my last few posts, I’ve talked about some of the foundations needed to build and deliver better software products. Product leadership can’t be left solely in the founder’s hands; there’s a benefit in hiring a product leader who can objectively validate and refine ideas, driving towards product market fit while the founder focuses on the business more broadly. I’ve also written about alignment attrition - why project teams lose their way, and how to minimize those risks by capturing shared understanding in visual artifacts.

But recent conversations with founders made me realize that many of them don’t understand the skills required to deliver on their product vision. More often than not, User Experience (UX) isn’t even on their radar. In my consulting career I’ve had this conversation hundreds of times, but today, the dialogue has shifted. Founders tell me, “I can hire a designer in India,” or, “I can do that with AI.” And it’s true - you can turn a Sharpie sketch into a wireframe, and then into code with today’s tools.

These founders are preserving their funds, because they worry about what seems like a significant up-front effort. But here’s what’s misunderstood: the real cost is in engineering. The design and definition phases - the first 5% of the overall effort - are about making sure all the human capital spent on engineering is actually moving in the right direction.

Skipping ahead to engineering is like starting construction before the architect has drawn the plans or before the builder understands who’ll live there.

The Quiet Power of the Right Roles

What most founders miss is that shaping real product direction and requirements requires Business Analysts and User Experience professionals - though in early-stage companies, these may not be dedicated seats. However, both types of insight are absolutely critical to whether your solution succeeds or fails.

The Product Manager / Business Analyst is the voice of business value. User Experience brings so much more than screen design - the UX practitioner is the advocate for the end user; a focus on screens risks product adoption in the long run. Both the business and user perspective ensure that crucial insights don't slip through the cracks.

The Bottom Line

This ties back to my post earlier this week about failed technology projects. Here’s the bottom line - the up-front 5% - the time and attention spent on discovering, defining, and aligning - is what separates products that limp into the market from those that leap in. Yes, the AI tool of your choice can spit out mockups. But if you skip the step of asking nuanced questions about who you’re building for, what problem you’re solving, and why, you’re introducing risk at the very outset.

So, before a single line of code gets written, have you invested in these perspectives? Are you inviting both business and user mindsets into the discovery process?

I'd love to hear from you. Have you ever regretted skipping the first 5%? How did thoughtful business analysis or user experience shape (or save) one of your projects? I’d love to hear your story - hit reply or share in the comments.

Success is improbable.

Most technology projects fail—some estimates suggest that 68% never meet their objectives. Emerging research indicates that AI projects fare even worse, with failure rates of 70–85%. In fact, nearly half of AI proofs-of-concept are abandoned before reaching production.

After decades of Agile, design thinking, and “fail fast” mindsets, why are outcomes still so poor?

Years ago, Harvard Business Review published an article by Jon Kolko entitled Dysfunctional Products Come from Dysfunctional Organizations. That insight holds true, but most conversations that I've seen on this topic to organizational design and process improvements as the solution. Necessary, maybe - but insufficient.

Why Do Projects Fail?

I've led many large ERP implementations and have overseen the development of hundreds of licensable and bespoke software solutions. Whether configuring solutions or building software from scratch, the challenges are largely the same:

• Unclear business goals. The goals are unclear, are not well aligned (or fail to adapt with) with the business opportunity, or have been poorly communicated. As the HBR article said "bad products point to bad alignment".

• Incomplete or shifting requirements. The product / service requirements are not adequately captured, leading to a lack of shared understanding (or divergent understanding) of the "why" over time.

• Misallocation of resources. When goals are vague, investments are harder to justify, and being “on time and on budget” can overshadow whether the right thing is even being built.

• Poor project hygiene. Weak planning, rework, unrealistic timelines, insufficient risk management, and governance breakdowns are the symptoms that cascade from the issues above.

In startups, the pressure to act or scale quickly can overwhelm the ability to pause, test, and iterate. In enterprises, the sheer number of stakeholders creates complexity that makes alignment brittle.

The deeper cause is what HBR described as alignment attrition. Teams begin with a shared vision, but over time, individuals make hundreds of micro-decisions that move them incrementally away from that vision. The result a slow drift away from the original vision and intent.

The Cure: Shared Visualizations

Fortunately, HBR proposes a pretty clear solution, and that is visualizing the product strategy in a consumable way. This is not a requirements document. It's not a set of screens either - the interface is not the strategy! Neither communicates the why.

True alignment requires shared visualizations of strategy - living artifacts that tell the story of intent, not just deliverables. When crafted well, they reduce drift, become rallying points, and unlock the IKEA Effect, because people value what they had a hand in shaping.

Some of the most effective alignment artifacts I’ve seen came from gifted User Experience leaders whose ability to visualize complexity provided senior stakeholders and project teams clarity about purpose and direction.

--

Projects don’t fail because of engineering or process alone. They fail because alignment drifts—and no one notices until it’s too late. A well-crafted visualization can anchor the “why” and keep teams on course.

👉 In your own work: how do you ensure alignment and keep your team on course over the life of a project ? I’d love to hear what has worked for you.

The Hiring Decision Founders Overlook: Why a Product Leader Is More Critical Than a Tech Co-Founder

Late last year I had the opportunity to provide guidance to a femtech founder who wanted to build a platform. She had a compelling idea for patients, but the value of the solution would never be realized if physicians didn't also engage. Unfortunately, the founder didn't truly understand the healthcare provider perspective, so she had no idea how to draw them to the platform. At the time, her attention was on finding a qualified engineering team to help bring her ideas to life. My recommendation to her was to get the product vision right before rushing to build something.

This is one of many such stories I've seen in my career - success measured in code written, rather than user needs and business outcomes clearly defined. In this post, I'll address why that's such a risk.

In my discussions with in early-stage FemTech startups - founders express urgency to identify a technical co-founder. Whether their backgrounds are in business or science, they are convinced that having technical guidance will transform their big idea into a scalable, successful product.

But what if that assumption is wrong? Over my many years of working on new product ideas, I’ve become convinced that the most overlooked, high-leverage collaborator isn’t an engineer - it's a product leader.

The Rush for Engineering Talent

I've seen the same pattern again and again - a founder eager to start building.

Never wanting to seem underprepared, the founder scrambles to recruit a technical co-founder, retaining product management responsibility (or sometimes outsourcing it). More and more, I'm hearing foundational aspects of the product innovation process delegated or delayed - “I can hire a designer in India” or "Maybe I’ll use AI to prototype the interface.”

When pressed, the founder's focus is often still “I need someone who can build this.”

Why Product Leadership Should Come First

Here is what I believe to be true after 20+ years of building new products and trying to salvage poorly conceptualized ones - engaging technical leadership before you have a clear product vision is putting the cart before the horse.

Placing a product leader at the center of the founding team isn’t just theoretical; it's a critical success factor. Yes, engineering talent is critical - but only after you’re sure about fundamental assumptions:

• Who is the customer?

• What is the problem you’re truly solving?

• Is this solution clinically and commercially viable, and does it excite actual users?

• Do we have a design or prototype that’s validated, even if it’s low-fidelity?

Of course, it's critical to make sure that product ideas are technically feasible. But if you hire an engineering leader and team too soon, suddenly there’s pressure to keep them busy writing code, shipping features even if the product direction is still a little hazy. This can mean building before you’re sure you’re building the right thing.

Build the Right Thing, Then Build the Thing Right

Instead, bringing in a product manager - someone with the confidence and experience to act as a "product sherpa" will:

• Lead the work of customer discovery and structured feedback, so you don’t just follow your instincts or clinical literature.

• Help validate initial concepts against real market, clinical, and user needs.

• Translate emotional user pain points and functional requirements into a roadmap that excites investors and future hires.

• Align your vision, business model, and regulatory realities so that you don’t end up with an amazing MVP that can’t be sold, reimbursed, or adopted in practice.

Starting with a product leader means your technical team will know what to build, and the team will have shared clarity about what success looks like.

Without these up front efforts, adding engineers often means burning cash on rework or walking back features, unnecessarily reducing your financial runway.

Your CPO as Strategic Thought Partner

Eventually, the right product leader will shape product direction in a way that is aligned with your original vision and what the market needs. That individual may eventually become your Chief Product Officer, not just plotting the product roadmap, but helping founders move beyond gut instinct to evaluate commercial potential, engage users, and manage regulatory risk. Those efforts generate insights and business value that investors demand.

The Founder’s Dilemma: Engineer or Product Lead?

It comes down to mindset: Is your most critical early question, “How do we build this?” Or is it, “What should we build, and for whom?”

Investing in product leadership first helps you:

• Pressure-test your foundational assumptions.

• Avoid the sunk-cost of building the wrong product.

• Set future engineers up for success with clear requirements and a validated vision.

Let’s Start a Conversation

If you’re a founder wrestling with new product direction and building the right team around you, I’d love to hear your experience. What has worked for you? What hasn’t? Are you prioritizing product leadership, or has engineering been the primary gap you’re trying to fill first?

As always, I’m committed to helping founders in digital health and FemTech navigate get compelling and impactful products to market. Let’s challenge the conventional wisdom—because building the right thing has to be prioritized before you can build the thing right.