Natalie Hanson, Ph.D.

Category: user experience

Dynamic Targeting
Reading Time: 5 minutes
A Case Study on Collaboration with UX and Data Science

Introduction

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.
18 March 2026
Personalized Analytics

Reading Time: 8 minutes
A Case Study on Collaboration with UX and Data Engineering

Last year I wrote about building AI-enabled solutions, and I promised to share some case studies which led me to develop framework I shared. If you haven’t read that initial post you can find it here – Building AI-enabled Solutions – Why a Human-Centered Lens is Key. This case study is mainly about Context and Users’ Mental Models – not much about Algorithm Design, which will be the primary focus of my next post.

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 when 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.

All these findings gave us a new understanding of a previously invisible bottleneck in sales – prepping for a physician interaction was a challenge and opportunity to be addressed. Our goal was to develop a new, complementary sales-enabling solution that was more grounded in the reps’ daily reality.

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.

Together with our consulting colleagues, we asked ourselves whether we could use proprietary algorithm to surface insights – with focus on consumption and immediate action – rather than analysis.

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.

Meaningful categories for the data inform how insights are presented in the user interface.

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.

11 March 2026
Better Diagnostics, Better Care – Critical Momentum in Women’s Health
Reading Time: 5 minutes

From an investment perspective, diagnostics is one of the most successful areas in women’s health right now. It makes sense – before we can deliver better innovation, better care, and better outcomes for women, we need a meaningful body of data about how female bodies works. Along with clinical research and sex-disaggregated findings, better diagnostics is key step in that journey.

It Still Sucks to Get Labwork Done

Last week I wrote about clinical trials and how hard it is to get women enrolled; the barriers are often mundane things like transportation and childcare. Getting diagnostic testing done is no different. I have several health conditions that require regular labwork, and I currently use three different labs, none of which are conveniently located. The closest one is 20 minutes away each way, and the furthest is closer to 40. If I weren’t so committed to my healing process (and if my kids were any younger), those would be insurmountable barriers.

Some incumbents are trying to close that gap by meeting people where they already are – LabCorp has integrated testing services into some Walgreens, and CVS offers similar options in select locations. Where I live, those options are still patchy. My “routine” labwork is an exercise in frustration, sucking time and energy I would frankly rather spend on anything else.

And all of that is modest compared to the days when I was rushing back and forth to the fertility clinic while trying to get pregnant, a time in my life when healthcare felt like a full time job.

Practical Solutions for Real Problems

This is the context in which at‑home testing and continuous monitoring start to feel like an opportunity for meaningful change and impact. If you’ve followed the evolution of diabetes care, you know that for years, patients were asked to test their blood sugar at prescribed intervals by pricking their fingers multiple times a day. Now continuous glucose monitors (CGMs) use a small sensor on the body to transmit readings to an app, collecting and communicating insights continuously.

Some women’s health tracking and diagnostic tools are moving in this direction as well. The Oura Ring is now widely known as a sleep and recovery tracker, but many women use it for cycle and readiness insights as well. Emerging products like the Incora earrings promise to use signals from the earlobe to infer hormone changes over time, turning jewelry a diagnostic solution.

Thankfully, I’m long past the stage of racing to the fertility clinic – my boys are 16 and 18 now – but I’m squarely in the phase of working with my doctor on hormone balancing. In spite of the improvements we’ve seen, getting to the lab is no more convenient than it was twenty years ago.

For months I scrolled past social media ads for Mira Fertility without much thought; their branding is very clearly aimed at people trying to conceive, and I am definitely done having kids! But my functional medicine doctor mentioned that some of her patients were using Mira for hormone tracking, and that the data was meaningfully changing how she prescribed hormone replacement therapy (HRT). Mira now offers dedicated kits for that use case.

So I decided to give it a try.

At‑Home Hormone Testing Is Easier – and in Some Ways Better – Than the Lab

The core shift with at‑home diagnostics is not just convenience, it’s density and continuity of data. Just like CGMs made the shift from one‑off readings to continuous insights and just-in-time alerts, at‑home hormone testing makes the shift from one-off data points into continuous insights.

When you first open the Mira app, you go through a short quiz about your cycle, goals, and current treatment. Those answers inform their recommendations for how often to test and which wands to use – for example, two specific wands near ovulation and one every other day the rest of the time. That protocol would be tedious and expensive if you tried to do it via lab draws; in an at‑home context, it’s very manageable.

The process is straightforward. Along with the wands, Mira includes a collapsible silicone cup for urine collection. You collect the sample, immerse one end of the wand for 15 seconds, dry it, then remove the cap on the opposite end and insert it into a small, egg‑shaped device that fits in your hand. After about 20 minutes, the device and app alert you that the reading is complete. One tap uploads the data and the app immediately generates appealing, easy to understand visual outputs:

My first‑morning urine is at 5 a.m. these days (thank you, menopause), so on the mornings when I need to test, I crack one eye open, start the test, and then go back to bed while the device does the work. I can sync and interpret the results when I’m actually awake an hour or so later. The app’s reminders for testing and syncing are present but not intrusive.

Two things have made this feel qualitatively different from my lab experience:
- The visuals are clear and legible, even when I’m half awake. I can see patterns emerging instead of trying to interpret one lonely lab value in a portal.
- The feedback loop with my doctor is faster. Even though the device measures hormones in urine rather than blood – admittedly a different window into what’s happening – within just a few weeks the outputs have informed changes to my HRT treatment.
Is it perfect? No. Even though I clearly indicated that I’m using the device for perimenopause and menopause, the articles and tips aren’t fully tailored to that stage of life. I understand that people trying to conceive are still Mira’s core market, but it’s a missed opportunity – women managing these hormone transitions are also also hungry for relevant information.

What This Signals for the Women’s Health Diagnostics Market

This is what meaningful diagnostics looks like when it actually respects women’s lives. Data from tools like Mira, Oura, and emerging devices such as Incora earrings don’t just help individual women; it also creates new opportunities for clinicians, payers, and product teams to understand the female body and experiences across large populations.

When that data is used respectfully, it can become a foundation for more responsive and precise treatment plans, early detection, and – the long game – evidence for imagining and building women’s health interventions that actually work.

From an investor’s perspective, that’s part of why diagnostics has become such a bright spot in women’s health. If you improve the fidelity, accessibility, and interpretability of data, you unlock better care and ultimately better outcomes for women.

From a product and UX perspective, the bar is also rising. This is where I spend most of my time professionally – helping teams build products and services in healthtech that are thoughtfully designed, and grounded in what real people can and will do.

Where We Go from Here

If you’re wrestling with hormones right now – whether that’s fertility, perimenopause, or ongoing chronic conditions – at‑home diagnostics can offer an accessible alternative to traditional labwork. It won’t replace your clinician, but it can provide insights that enable a more responsive, personalized approach to care.

I’d love to hear how this lands for you—especially if you’re a fellow midlife hormone explorer or a founder working on diagnostics or women’s health. If you’re curious about how to shape products and experiences that are both clinically meaningful and deeply humane, I’d welcome the opportunity to continue the conversation with you.
20 February 2026
Beyond Features and Launch Plans: The Human Side of Product Adoption
Reading Time: 6 minutes
When adoption fails, it’s rarely about the technology — it’s almost always about people.

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.
29 January 2026
Bury the Anthropology? Why Human-Centered Insight Is a Tech Superpower
Reading Time: < 1 minute
Throughout my career, coaches and recruiters have told me to “bury the anthropology.”

“It’s confusing.”

“It’s a liability.”

“It’s a distraction.”

Yesterday, for the first time, an LLM said: “Keep it – it’s a differentiator.” I don’t need validation from a model, but it highlights a bigger problem in tech – software organizations still undervalue team members who deeply understand people.

I’ve worked across the product lifecycle from new product development to post-sales support, and every role I’ve had depended on understanding human behavior.

If you build software without people at the center of your efforts, you pay for it later in a multitude of ways:
- Costly engineering rework instead of rapid iterations on a prototype
- High support volume that’s triggered by UX and training debt
- Low adoption and churn because real behavior wasn’t accounted for
Throughout my career, I’ve seen the same patterns again and again:
- Help desk calls where “technical issues” were the result of poorly designed or implemented software
- Sales Ops findings that revealed systems built for executive decision-making, not facilitating reps work with customers
- Stakeholders driving product requirements instead of listening to users
- Measurable improvement in algorithms that consider human behavior
- Post‑sales experiences that make-or-break customer relationships
The urgent need in tech is more leaders who recognize that understanding humans is central to building a successful software business.

Where in your product lifecycle are you still guessing about human behavior?

Read the full post on Substack.
7 January 2026
Bury the Anthropology? Why Human-Centered Insight Is a Tech Superpower
Reading Time: 4 minutes
From product market fit to post-sales support, anthropology and human-centered design de-risk software, reducing rework and driving adoption, retention, and SaaS growth.

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 salespeople, I translated my observations into recommendations for interfaces and workflows that reduced friction and enabled the reps to focus on their customers.

A (redacted) week in the life of a Large Enterprise Account Executive. Blue represents time spent on internal systems and processes, orange time spent engaging with customers. (c) 2009 Melissa Visintin

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.
7 January 2026
Building AI-enabled Solutions – Why a Human-Centered Lens is Key
Reading Time: 4 minutes
Here’s how 20 years of cross-disciplinary exploration shaped my approach to building AI-enabled solutions, and why teamwork matters now more than ever.

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.

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.
(more…)
17 September 2025
Are We Measuring What Matters to Customers?

Reading Time: 2 minutes
Are your metrics really about your customers – or just your own achievements? Here’s why I am refreshing my measurement framework.

Are We Measuring Value – Or Just Ourselves?

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 sounds 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:

From Lynn Hunsaker’s article, linked above.

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?

9 September 2025
From Vanity Metrics to Business Outcomes
Reading Time: 4 minutes
(and Why “Musk Metrics” Are the Worst)

From the early days of my work in User Experience, I realized that people’s lack of understanding about the field meant I was going to have to speak in their terms about the impact my team and our services were making.

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
The Faros AI report – https://www.faros.ai/blog/ai-software-engineering

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!
3 September 2025
Are You Getting the First 5% Right?

Reading Time: 3 minutes
What Founders Miss Before Engineering Even Starts

Design Thinking’s double diamond is a visual framework; the first diamond depicts understanding the problem and second finding the right solution.

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 – please share in the comments.

28 August 2025
Most Technical Projects Fail – But Not for the Reasons You Think

Reading Time: 2 minutes
Solving for alignment attrition

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.
(more…)

26 August 2025
BCG Weighs in on Women’s Health

Reading Time: < 1 minute
BCG is adding their name to the mix of companies acknowledging the huge market potential in “women-focused products and services”.

Some investors have called women’s health a ‘niche’ market, and investors believe that there are “riches in niches”. However, the women who live with sub-par scientific knowledge about their bodies and healthcare gaslighting make up 51% of the population – we are not a niche!

BCG joins McKinsey, KPMG, and others to articulate what many others like WHO, ARPA-H, NIH, NAS, WHAM, SHRM and others have already – consumer / patient needs aren’t being met, and there is value to be generated and money to be made. This is a market ripe for innovation, disruption, and even aggregation. And hopefully, at the end of it all, better healthcare for women.

I’ll be writing more about this in 2025, but in brief – there is work to be done in scientific research (inclusion and proper analysis of female experiences), care delivery, bi-partisan policy and so much more … I’m excited to see what the future holds as innovators, investors, policy makers, and health care professionals lean in!

The summary of Key Findings is available on the BCG website.

17 December 2024