Product strategy grounded in evidence, with a bias for the hard question no one's asking yet. Healthcare AI, medtech, drone logistics, enterprise CRM, veteran services — complex environments where getting the diagnosis right matters more than moving fast.
AI-assisted self-diagnosis on BestBuy.com, built from 25 years of Geek Squad call transcripts. Later evolved into a triage model across all Best Buy-supported products.
Customers had no way to diagnose their own device issues before contacting service. Without that, calls came in misclassified, store visits were often unnecessary, and some customers abandoned repairs entirely rather than deal with the effort of figuring out where to start.
Customers were already weighing repair against replacement — they just didn't have the numbers to decide. Device value, trade-in, and new pricing in the same flow would have turned a service visit into a sale.
A self-service diagnostic tool that helped customers troubleshoot their own devices, surfaced a repair-or-replace estimate at the right moment, and used what customers chose to improve their decision making.
Participants screened for recent device issues to ensure close-to-real-world scenarios. Methods included competitive analysis, field studies with Geek Squad agents, customer interviews, unmoderated remote usability testing on desktop and mobile, heuristic analysis, and dot voting.
80% of test participants said they would use the feature in real life. Most participants were unaware Best Buy offered computer repair — a significant gap surfaced through research, not marketing. Users found the interaction length appropriate and logically sequenced but expected pricing and timing options. The repair-or-replace decision was identified as a missed opportunity.
Pricing and timing estimates at point of diagnosis. Auto-authentication and device auto-recognition. Improve DIY and troubleshooting databases. Geek Squad Chat integration and on call remote service. Taxonomy study to better map user mental models.
Service blueprint mapping customer flow, system decision logic, and technology touchpoints at each stage. Conversational design and microinteractions guides covering dialogue structure, language patterns, and interface cues. Decision tree, wireflows, high-fidelity design for mobile and desktop, copy deck, MVP question framework.
As a customer with a malfunctioning device, I need to understand what's wrong without calling or visiting a store, so I can decide what to do next.
As a customer considering repair, I need to see my device's current value and trade-in offer alongside repair cost, so I can make an informed decision.
Conversational interface trained on Geek Squad call transcript data. Automated issue classification and recommended next action. Integration with device trade-in valuation and current pricing. Handoff path to scheduling or purchase if customer chooses to act.
Live agent escalation, warranty verification, third-party device support, remote diagnostics
Case study available on request
Led discovery and strategic roadmap for CHS Source, the internal intranet for a Fortune 100 agriculture and energy company with 11,000 employees across the US, Middle East, South America, and Asia.
Research included interviews, surveys, site analytics, and heuristic evaluation across office and field employees, managers and frontline staff.
Search was distrusted. Navigation reflected the org chart, not how people actually worked. Content was almost entirely HQ-facing — announcements and social events that meant nothing to someone troubleshooting equipment in the field. The team managing it were content creators. They'd never framed the intranet as a utility people depended on to get their jobs done.
The people managing the intranet had never considered who couldn't use it. Half the workforce were field workers with no office computer — expected to complete health plan enrollment on a platform they couldn't reliably reach. Some employees didn't work in English. The product had been built by and for headquarters, and nobody had questioned that until the research brought it to light.
A phased roadmap reframing the site around what employees actually needed to do — not what headquarters wanted to publish. A product-level strategy tied to communications and corporate objectives. And a working model the internal team could carry forward without ongoing outside help.
Interviews, surveys, web analytics, and heuristic evaluation across office and field employees, managers and frontline staff, domestic and international — across 12 business lines.
Search was effectively broken and distrusted. Third-party application silos had made the site unsupportable — decoupling was an immediate priority. Field workers with no office computer had no reliable path to complete health plan enrollment. Navigation reflected the org chart, not how people worked.
Kiosk and tablet-based enrollment portals for non-office locations. Deep linking between frequently used tools. Tagging and content management by role and geography. Bookmarking and customization for employee tools. Fast-find modules for high-traffic needs — benefits, enrollment, HR tasks. Single access point for division and business group microsites. Employee and location-specific content targeting. Career path tools and guidance.
Four product objectives defined spanning findability, role-relevant content, user customization, and shifting the site from company publishing to employee utility. Working model left with the internal team to carry forward without ongoing outside help.
As a field employee, I need to complete benefits enrollment without visiting an office or relying on a work computer, so I can access what I'm entitled to without barriers.
As a corporate employee, I need to find tools and HR resources quickly without navigating through company news, so I can do my job without friction.
As a manager, I need access to hiring, training, and HR information in one place, so I'm not dependent on email or phone to get answers.
Navigation restructured around tasks rather than org chart. Role and location-based content personalization and tagging. Search UI with filtering and sorting. Bookmark and customization capability for individual employees. Kiosk or tablet-based enrollment path for non-office field locations. Deep linking into HR tasks and benefits workflows. Single sign-on exploration and third-party app decoupling strategy.
Full third-party application decoupling, content migration, new content creation, development execution
Case study available on request
E-commerce lead for DroneUp's drone delivery platform — a logistics company running a consumer product for the first time, with a Fortune 1 Walmart partnership at stake. Identified critical purchase blockers, built research infrastructure from scratch, and delivered customer-facing experiences across web, mobile, and Walmart.com integration.
Customers within delivery range were hitting a dead end with no explanation. If a hub was down for weather, maintenance, or outside operating hours, the site returned nothing. No feedback, no alternative, no path forward. Separately, a proposal was circulating to remove guest checkout entirely — with no data behind it and no one asking why.
60–70% of behavioral data was contaminated by internal employee testing. Every metric being used to make product decisions was noise — there was no clean read on actual customer behavior anywhere in the system. The guest checkout proposal was the same pattern: a logistics team running a consumer product, making sales decisions without consumer product instincts.
Research infrastructure built from available resources — chat logs, employee testing, piggybacked marketing research — that produced a clean behavioral baseline for the first time. A direct case to the CEO reversed the guest checkout decision mid-meeting. The larger shift was the same in both cases: from operations thinking to product thinking.
Built research operations with no formal budget. Pulled themes and direct quotes from customer service chat logs (Zoho) and reported monthly to e-commerce and senior leadership. Ran moderated testing with new employees when usability tools weren't approved. Partnered with the marketing director to attach research questions to her existing market studies.
Partnered with data science to purge employee work and personal email addresses from the analytics platform, producing the first clean customer behavior baseline.
Delivered customer-facing e-commerce experiences across three surfaces: DroneUp web (V1 on WooCommerce, V2 on custom platform), DroneUp mobile app, and Walmart.com integration. Produced personas, user journeys, site architecture, and address verification flows supporting the purchase path work.
As a customer within delivery range, I need to understand why delivery isn't available right now, so I can decide whether to wait or come back later.
As a product team, we need behavioral data that reflects actual customers rather than internal testers, so we can make decisions based on reality.
As a customer expecting Amazon-level responsiveness, I need real-time status and communication during my delivery, so the experience matches what I'm used to.
Hub status feedback surfaced at point of purchase — weather, maintenance, operating hours. Guest checkout path cleared of unnecessary friction. Address verification flow improvements. Internal employee traffic filtered from behavioral metrics. Monthly research reporting cadence established. Usability testing framework built within zero or minimal budget constraints.
Walmart.com integration build, vendor portal, flight operations software, pilot-facing tooling
Case study available on request
After a restructuring eliminated the entire product leadership for the vendor portal, no one left in the company understood what it was or what was at stake if it didn't ship. The platform wasn't an internal ops tool — it was the client relationship layer for every enterprise partner and the order management surface for their end customers.
The institutional knowledge for the vendor portal walked out the door with three people. There was no champion, no documentation, and no one left who could explain why the platform mattered to anyone with budget authority.
Leadership's blindspot was their own point of view: they thought in logistics terms, so clients would get logistics tools. They proposed a platform (HubOps) built for FAA-certified pilots as the client-facing solution. The actual need was entirely different: every enterprise partner needed their own visibility into live orders, margins, FAA-approved inventory and location performance at the right permission level. Without it, every new client relationship was manual with no path to scale.
A client-facing, role-based platform that made DroneUp sellable at enterprise scale — pricing, ordering, mission visibility, delivery margins, and multi-location controls surfaced for the right person at the right permission level. Setting a path forward for the 300–500 daily missions per hub that the Walmart partnership required, and every future client would expect.
Made the case to tech leadership, C-suite, marketing, and operations until budget and resources were assigned. Only person remaining who understood the platform's scope and could articulate the business case across audiences. Iterated wireframes and key visuals collaboratively with the Director of E-commerce before the restructuring, then carried the work forward solo — presenting across departments until a team was funded.
Enterprise partners had no way to manage their own delivery operations without going through DroneUp manually. Every new client relationship required internal mediation with no path to self-service or scale.
As a Walmart store manager, I need live order and delivery visibility for my location so I can manage customer expectations without contacting DroneUp directly.
As a regional director, I need cross-location visibility with appropriate permission controls so I can monitor performance at scale.
As an integration partner, I need API pathways into my existing platform so drone delivery becomes a native option rather than a separate workflow.
As a merchant, I need to manage my own pricing, products, and delivery margins so I control my own business outcomes.
Role-based permissions supporting store, regional, and enterprise access. Live order and mission status visibility per location. Margin and revenue reporting per merchant. Product and pricing management per vendor. Multi-location dashboard. API integration pathways for merchant platforms.
HubOps internal operations, pilot-facing tooling, FAA compliance workflows, consumer-facing e-commerce
Case study available on request
A 20-year-old CRM was failing across a global client-facing workforce. And a new system was being layered on top of the old one.
EY's CRM adoption had collapsed across a global organization of client-facing professionals — auditors, tax advisors, M&A specialists. The platform had accumulated two decades of technical debt and had never recovered a meaningful user base. Leadership framed it as a product problem. Multiple agencies had cycled through before this project. None produced findings that changed the organization's direction.
The frontline professionals being asked to log client data had no incentive to do it. Strategic advisors above them wanted that data to identify cross-sell opportunities — but the people entering it weren't seeing any of the upside. The ask was essentially portfolio management work on top of their actual jobs, for someone else's benefit. That's not a feature problem. It's a structural one.
Rather than delivering a longer backlog, the engagement delivered a reframe: the old platform was too far gone for feature investment to move the needle, and the new one needed the incentive structure to exist before any product work would stick.
40+ interview hours across stakeholders and users in multiple regions. Over 1,200 discrete data points. Research synthesis that surfaced what prior agencies hadn't. As EY's Director of Digital Strategies and Solutions put it: "You are the only one who told us 'the why' of what our users are thinking and doing."
CRM adoption had failed across EY's global sales organization. The platform was technically functional but practically unused. Prior agency engagements had not produced findings that changed organizational direction. Leadership attributed the failure to the product; the actual failure was upstream of it.
As a sales leader, I need to understand why adoption has failed so I can stop investing in the wrong solution.
As a salesperson, I need to trust that the data in the system reflects reality before I'll contribute to it.
As an EY executive, I need a research-backed rationale for changing direction that I can defend internally.
Conduct structured discovery across user segments and organizational levels. Synthesize findings into a root cause diagnosis with supporting data. Deliver a strategic recommendation with implementation sequencing. Frame findings in terms of organizational decision-making, not feature prioritization.
Feature specification, UX design, technical architecture, platform evaluation or vendor selection
Case study available on request
Led product-level discovery for Intuitive Surgical's robotic surgery training platform — the learning application tied to the Da Vinci system's $1.5M sales pipeline. The platform was failing its core audience, and the company had no framework for understanding why or what to prioritize.
The learning platform (IL 9.0) was a custom-built web and mobile application that had never received sustained product investment. Surgeons learning robotic-assisted techniques couldn't track progress, search content effectively, or navigate basic UI patterns. The result: dedicated learners abandoned the platform entirely, building their own Facebook groups and YouTube channels to share methods and training content.
Leadership framed it as a usability problem needing a redesign. The actual gap was strategic: there was no model for what the platform should be doing across the surgeon's learning lifecycle — from first login through certification to ongoing skill development. Without that, every feature request was disconnected from outcomes, and a year-long redesign would have produced the same directionless product with newer UI.
A modified Google HEART framework tailored to the novice-to-certified surgeon journey — seven objective columns (adoption, engagement, navigation, retention, milestone completion, confidence, ongoing improvement) with defined outcomes, metrics, and tactics mapped to each. Not just a deliverable but an operating model the team could use to prioritize, measure, and evolve the platform as the product matured.
Two-tier roadmap: 13 immediate fixes deployable on the existing 9.0 platform with minimal dev resources (breadcrumbs, progress visibility, searchable content index, hover states, merged catalogs, onboarding improvements) and 10+ visionary features for 10.0 requiring research validation (gen-AI or personalized glossaries, spaced repetition, experience points, peer comparison, case-based content recommendations, community contributions). Advocated for iterative delivery over a proposed year-long "Big Design Upfront" method redesign that would have deferred all validation and made failure expensive.
Platform adoption was underperforming among the surgical professional population it was built for. Surgeons were routing around the product to unofficial Facebook and YouTube communities for training content. The organization attributed the failure to missing features and proposed a year-long build cycle with deferred validation.
As a surgical professional, I need training content that works within my actual time constraints and workflow — not a platform I have to work around.
As a product leader, I need a roadmap that distinguishes between what we can fix quickly and what requires sustained investment.
As a clinical stakeholder, I need confidence that we're not spending a year building against unvalidated assumptions.
Conduct discovery with surgical professional users to identify usability and trust gaps. Map workaround behavior to specific platform failure points. Deliver tiered roadmap with implementation sequencing rationale. Provide recommendation on build cycle structure with supporting evidence.
Feature design, content development, clinical training curriculum, engineering specification
Case study available on request
Directed usability research across a Series A multilingual interpretation platform used by the European Parliament, Interpol, NATO, and the United Nations. Broad mandate with narrow budget: explore the product suite, introduce research practices, and demonstrate value to a company that had been told not to use the word "research" around its founders.
KUDO had experienced a massive COVID-driven growth spike and was stretched past its limits. Six applications were in various states of development with no usability feedback loop, no research infrastructure, and a product/founder leadership openly hostile to the idea. The VP of Product who brought me in was fighting that battle at the executive level while I worked across the product suite.
The resistance wasn't really about research — it was about a hardware company's identity. KUDO had built its reputation on physical interpretation booths. The digital products were new, and leadership was still thinking in terms of shipping features to keep up with demand, not building products that could sustain the growth. The interpretation-side executives and implementation leads understood the gap immediately. The product/founder side didn't.
A lightweight research framework the company could run without me — moderated testing kit, scripts, severity matrix, observer guides — handed to the UI designers and localization team. Validated an AI-powered interpreter assistant through two pilots and six moderated sessions. Contributed findings across six applications, delivered directly to the VP of Product through findings decks, live observation, and raw notes.
Ran guerrilla-style research across six applications: Interpreter Assistant (AI glossary builder for event preparation), Live Interpretation Autosuggestor (real-time word suggestion during live multilingual sessions), KCP core platform, Conference Console, Marketplace, and client onboarding.
Built reusable research toolkit (test plans, scripts, surveys, severity matrix). Conducted contextual interviews with interpreters, implementation leads, and marketplace stakeholders. Findings fed into VP of Product's development and production decisions.
Case study available on request
Redesigned a globally-used IT infrastructure monitoring application — transforming an engineer-built legacy system into an accessible platform for enterprise network administrators. Delivered 60% under budget as a three-person team with the client's strategist and CTO.
Nagios XI had significant market presence but an interface that reflected how it was built — by engineers, without sustained attention to the administrators who used it daily. New users memorized non-intuitive steps and blamed themselves for not finding features. Long-time users had built workarounds so ingrained they'd resist any change to them. The product served airlines, defense contractors, governments, and enterprise retailers monitoring everything from server health to nuclear reactor temperature gauges — and the interface hadn't kept pace with that scale or those stakes.
The product's complexity looked like a feature. Power users had internalized workarounds that made the tool functional for them, which masked the severity of the problem for everyone else. The system had never been evaluated against its actual user spectrum — the Learner who doesn't yet know the platform, the Legend who exploits every shortcut, and the Legacy user who will fight any change to their workflow. Without that lens, every improvement risked solving for one group at the expense of another.
A modernized platform scoped to how enterprise network administrators actually work — accessible under operational pressure, navigable across permission levels, and built around monitoring workflows rather than the full range of what the system could technically expose. Not a rebuild but a reorientation: the same trusted, feature-rich application redesigned around its user instead of its architecture.
Heuristic analysis at global and page level. Information architecture redesign and wireframes. Visual design for desktop including interactive homepage prototype. Stakeholder and user interviews across global user base. Applied complexity frameworks (institutional, environmental, informational, integration) and modified usability heuristics for expert-domain applications — safe exploration, guardrails, bulk actions, learning cues, spatial predictability. Created user archetypes (Learner, Legend, Legacy) to evaluate every navigation and hierarchy decision against the full experience spectrum. Delivered as a three-person team, 60% under budget.
Nagios XI's interface reflected the engineering environment that produced it rather than the operational needs of the network administrators who used it daily. Usability debt had accumulated over time. Accessibility gaps created compliance exposure in enterprise accounts. The product's complexity was masking adoption friction rather than indicating product depth.
As a network administrator, I need to identify and act on infrastructure issues quickly without having to reconstruct what the system is telling me.
As an enterprise IT leader, I need the platform to meet accessibility requirements so I can deploy it across my organization.
As a product leader, I need the redesign to preserve the monitoring depth existing users rely on while opening the product to a broader administrative audience.
Discovery with enterprise network administrator user segment to identify primary workflow friction points. Accessibility audit against enterprise compliance standards. Interface redesign scoped to primary monitoring workflows. Preservation of advanced functionality for power user segment.
Backend architecture changes, monitoring engine modifications, feature additions beyond scope of redesign brief
Case study available on request
A 20-year-old acquired platform was carrying two separate problems: a patient intake process with hidden workflow inefficiencies, and no design system — which meant every developer on the product was solving the same problems independently.
PointClickCare had acquired a long-tenured platform without inheriting a coherent product foundation. The patient intake process had accumulated inefficiencies invisible at the feature level — the workflow appeared functional but broke down in practice. Separately, the platform had no design system, which meant 20+ developers were making independent interface decisions across a surface area that required consistency to be trustworthy in a clinical environment.
The intake inefficiencies weren't a UX problem in the surface sense — they were workflow problems that manifested in the interface. The actual friction was upstream of what users were clicking. On the design system side, the cost wasn't obvious until it was quantified: independent decisions across 20+ developers, compounded over time, represented an estimated $335k in annual redundant effort. That number made the business case legible in terms leadership could act on.
A redesigned intake process scoped to the actual workflow rather than the assumed one, and a design system that gave the development team a shared foundation — reducing redundant effort, improving consistency, and making the platform more defensible in clinical procurement evaluations where trust in the interface is a purchasing factor.
Redesigned patient intake from a 6,500-pixel static form to a modular UI after field research revealed the 5-minute analytics time masked a 2-hour actual process — specialists were collecting everything on sticky notes and whiteboards before entering data. Delivered five digitized intake tools addressing EHR interoperability (lead tracking, intake redesign, IVR touch-tone translator, document repository with role-based filtering, bulk patient import for agency mergers).
Built design system across three layers — building blocks (color, type, grid, icons), UI patterns (templates, modules, components, elements), and rules (design principles, implementation guidelines, editorial guidelines) — with a seven-phase implementation strategy and a projected 15% savings on $2.25M annual development cost across three teams.
An acquired platform carried two compounding problems: a patient intake process with hidden workflow inefficiencies not visible at the feature level, and no design system — leaving 20+ developers making independent interface decisions across a platform where clinical consistency is a trust requirement.
As a clinical staff member, I need the intake process to reflect how the workflow actually runs — not how it was assumed to run when the interface was built.
As a developer, I need shared foundations so I'm not solving the same interface problems independently on every sprint.
As a product leader, I need the design system investment justified in terms the business can evaluate.
Workflow discovery with clinical staff to identify upstream friction points in intake process. Intake redesign scoped to actual workflow rather than interface symptoms. Design system covering primary interface patterns across platform. Business case documentation quantifying redundant effort savings.
Backend system changes, clinical workflow policy, platform feature additions outside intake scope
Case study available on request
Dan's grasp of web development and trends has really allowed us to push
the envelope.
Dan is always thinking outside the box and bringing fresh, creative ideas.
We had 'Microsoft', and Dan
gave us 'Apple'.
I sing Dan's praises as often
and loudly as I can.
Do yourself a favor — hire Dan,
and you can thank me later!
Dan knocks it out of the park.
He's flat-out terrific.
Dan has done absolutely
the best analysis for our product!
90% of where our platform is today
is due to Dan's vision.
Dan's improvements only require
20% effort to implement, but have
an 80% impact.
His research gave us the needed
step to move us forward.
Dan does 'Class A' work.
We've had countless agencies do research for us, but Dan is the only one who told us 'the why' of what our users are thinking and doing.
He is a rare combination of strategic thinking, strong craft and a genuine empathy for users.
Dan has done phenomenal work
for our E-Commerce Platform.
He's irreplaceable!
Dan is the deadly combo of User Experience and Product Management.
It's insane.
In 'professional environments',
not everyone is always professional.
Dan IS always a professional!
No one seems to know where our product needs to go more than Dan.
Dan's ability to adapt to evolving projects and stay focused on customers' needs sets him apart.
Dan is insightful and diligent on making sure that the user comes first in everything he touches.
Dan's insight, direction, sense
of urgency, and long-term vision
was invaluable.
Dan has a vast and
understanding mindset.
Dan's grasp of web development and trends has really allowed us to push
the envelope.
Dan is always thinking outside the box and bringing fresh, creative ideas.
We had 'Microsoft', and Dan
gave us 'Apple'.
I sing Dan's praises as often
and loudly as I can.
Do yourself a favor — hire Dan,
and you can thank me later!
Dan knocks it out of the park.
He's flat-out terrific.
Dan has done absolutely
the best analysis for our product!
90% of where our platform is today
is due to Dan's vision.
Dan's improvements only require
20% effort to implement, but have
an 80% impact.
His research gave us the needed
step to move us forward.
Dan does 'Class A' work.
We've had countless agencies do research for us, but Dan is the only one who told us 'the why' of what our users are thinking and doing.
He is a rare combination of strategic thinking, strong craft and a genuine empathy for users.
Dan has done phenomenal work
for our E-Commerce Platform.
He's irreplaceable!
Dan is the deadly combo of User Experience and Product Management.
It's insane.
In 'professional environments',
not everyone is always professional.
Dan IS always a professional!
No one seems to know where our product needs to go more than Dan.
Dan's ability to adapt to evolving projects and stay focused on customers' needs sets him apart.
Dan is insightful and diligent on making sure that the user comes first in everything he touches.
Dan's insight, direction, sense
of urgency, and long-term vision
was invaluable.
Dan has a vast and
understanding mindset.
Dan's grasp of web development and trends has really allowed us to push
the envelope.
Dan is always thinking outside the box and bringing fresh, creative ideas.
We had 'Microsoft', and Dan
gave us 'Apple'.
I sing Dan's praises as often
and loudly as I can.
Do yourself a favor — hire Dan,
and you can thank me later!
Dan knocks it out of the park.
He's flat-out terrific.
Dan has done absolutely
the best analysis for our product!
90% of where our platform is today
is due to Dan's vision.
Dan's improvements only require
20% effort to implement, but have
an 80% impact.
His research gave us the needed
step to move us forward.
Dan does 'Class A' work.
We've had countless agencies do research for us, but Dan is the only one who told us 'the why' of what our users are thinking and doing.
He is a rare combination of strategic thinking, strong craft and a genuine empathy for users.
Dan has done phenomenal work
for our E-Commerce Platform.
He's irreplaceable!
Dan is the deadly combo of User Experience and Product Management.
It's insane.
In 'professional environments',
not everyone is always professional.
Dan IS always a professional!
No one seems to know where our product needs to go more than Dan.
Dan's ability to adapt to evolving projects and stay focused on customers' needs sets him apart.
Dan is insightful and diligent on making sure that the user comes first in everything he touches.
Dan's insight, direction, sense
of urgency, and long-term vision
was invaluable.
Dan has a vast and
understanding mindset.
Dan has a tendency to side with users in discussions, even when it conflicts with product vision.
He introduces a lot of questions at the beginning of projects. It can delay momentum.
Dan kept asking if we had data to support decisions. We prefer to move quickly based on instinct.
He pushes back on decisions that seem obvious to the team. It can create friction.
Dan doesn't always align with leadership priorities. He tends to reframe things around the user.
He focuses a lot on usability details. We're more focused on the bigger picture.
Dan sometimes struggles to fully buy into the product philosophy.
He prefers to test and iterate before committing. We're more comfortable making bold decisions early.
Dan asks a lot of questions. It's over-analysis when we can just copy this other app.
He tends to slow things down to make sure we're building the right thing. We're trying to move fast.
Dan doesn't always go along with group decisions if he feels they're not user-centered. And that's not a team attitude.
He often expands the scope to include research or validation steps. We don't have budget to talk to users.
He brings conversations back to users when we're trying to focus on internal goals.
Dan revisits topics like research and usability multiple times, even after we've moved on.
He measures success in terms of user clarity and experience. We look at our new clients we signed. That's proof.
Dan sometimes wants to do wireframes, because he says it's the interaction model. Who still uses Axure?
Tell me why we need to do research again?
It's been six months of user testing, so maybe we should reevaluate if research helps us or not.
He suggested we look at the data for a few minutes. We don't need to be moving around Post-it notes for two weeks.
Dan said he works for the user. He has a lot to learn about org charts and who signs his checks.
We don't need to do user testing. Somebody told me the other day how much they liked the app.
I told him not to say the word research to the CTO. And he did. And showed him a report.
I don't know why he wanted to make toast messages. We all just wanted to make the screen really bright so people knew something was different.
He was arguing a point the whole team disagreed with. It was really rude. And I told him so.
He overthinks things.
We just need to speak about the product with more confidence. Not more UI designs.
He said he'd put on an orange vest, get a clipboard and go to Walmart. We can't ask the client to ok that.
If we ask clients for feedback loops, we're admitting our product is broken.
If people don't want to figure out our app, then we won't reward them.
We don't want everyone in the app. Just the right people.
Dan won't use my free app. You upload a JPG and ask someone to find a button. Then, it's scientifically tested!
Dan kept asking what the user gets out of the first five minutes. That's not really how this product works.
I don't know why he spends time making recruitment creative. We have proven messaging doesn't matter, only frequency.
I don't know why he does user testing. We know in MS Teams messages if someone in the company doesn't like a feature in the app.
Dan has a tendency to side with users in discussions, even when it conflicts with product vision.
He introduces a lot of questions at the beginning of projects. It can delay momentum.
Dan kept asking if we had data to support decisions. We prefer to move quickly based on instinct.
He pushes back on decisions that seem obvious to the team. It can create friction.
Dan doesn't always align with leadership priorities. He tends to reframe things around the user.
He focuses a lot on usability details. We're more focused on the bigger picture.
Dan sometimes struggles to fully buy into the product philosophy.
He prefers to test and iterate before committing. We're more comfortable making bold decisions early.
Dan asks a lot of questions. It's over-analysis when we can just copy this other app.
He tends to slow things down to make sure we're building the right thing. We're trying to move fast.
Dan doesn't always go along with group decisions if he feels they're not user-centered. And that's not a team attitude.
He often expands the scope to include research or validation steps. We don't have budget to talk to users.
He brings conversations back to users when we're trying to focus on internal goals.
Dan revisits topics like research and usability multiple times, even after we've moved on.
He measures success in terms of user clarity and experience. We look at our new clients we signed. That's proof.
Dan sometimes wants to do wireframes, because he says it's the interaction model. Who still uses Axure?
Tell me why we need to do research again?
It's been six months of user testing, so maybe we should reevaluate if research helps us or not.
He suggested we look at the data for a few minutes. We don't need to be moving around Post-it notes for two weeks.
Dan said he works for the user. He has a lot to learn about org charts and who signs his checks.
We don't need to do user testing. Somebody told me the other day how much they liked the app.
I told him not to say the word research to the CTO. And he did. And showed him a report.
I don't know why he wanted to make toast messages. We all just wanted to make the screen really bright so people knew something was different.
He was arguing a point the whole team disagreed with. It was really rude. And I told him so.
He overthinks things.
We just need to speak about the product with more confidence. Not more UI designs.
He said he'd put on an orange vest, get a clipboard and go to Walmart. We can't ask the client to ok that.
If we ask clients for feedback loops, we're admitting our product is broken.
If people don't want to figure out our app, then we won't reward them.
We don't want everyone in the app. Just the right people.
Dan won't use my free app. You upload a JPG and ask someone to find a button. Then, it's scientifically tested!
Dan kept asking what the user gets out of the first five minutes. That's not really how this product works.
I don't know why he spends time making recruitment creative. We have proven messaging doesn't matter, only frequency.
I don't know why he does user testing. We know in MS Teams messages if someone in the company doesn't like a feature in the app.
Dan has a tendency to side with users in discussions, even when it conflicts with product vision.
He introduces a lot of questions at the beginning of projects. It can delay momentum.
Dan kept asking if we had data to support decisions. We prefer to move quickly based on instinct.
He pushes back on decisions that seem obvious to the team. It can create friction.
Dan doesn't always align with leadership priorities. He tends to reframe things around the user.
He focuses a lot on usability details. We're more focused on the bigger picture.
Dan sometimes struggles to fully buy into the product philosophy.
He prefers to test and iterate before committing. We're more comfortable making bold decisions early.
Dan asks a lot of questions. It's over-analysis when we can just copy this other app.
He tends to slow things down to make sure we're building the right thing. We're trying to move fast.
Dan doesn't always go along with group decisions if he feels they're not user-centered. And that's not a team attitude.
He often expands the scope to include research or validation steps. We don't have budget to talk to users.
He brings conversations back to users when we're trying to focus on internal goals.
Dan revisits topics like research and usability multiple times, even after we've moved on.
He measures success in terms of user clarity and experience. We look at our new clients we signed. That's proof.
Dan sometimes wants to do wireframes, because he says it's the interaction model. Who still uses Axure?
Tell me why we need to do research again?
It's been six months of user testing, so maybe we should reevaluate if research helps us or not.
He suggested we look at the data for a few minutes. We don't need to be moving around Post-it notes for two weeks.
Dan said he works for the user. He has a lot to learn about org charts and who signs his checks.
We don't need to do user testing. Somebody told me the other day how much they liked the app.
I told him not to say the word research to the CTO. And he did. And showed him a report.
I don't know why he wanted to make toast messages. We all just wanted to make the screen really bright so people knew something was different.
He was arguing a point the whole team disagreed with. It was really rude. And I told him so.
He overthinks things.
We just need to speak about the product with more confidence. Not more UI designs.
He said he'd put on an orange vest, get a clipboard and go to Walmart. We can't ask the client to ok that.
If we ask clients for feedback loops, we're admitting our product is broken.
If people don't want to figure out our app, then we won't reward them.
We don't want everyone in the app. Just the right people.
Dan won't use my free app. You upload a JPG and ask someone to find a button. Then, it's scientifically tested!
Dan kept asking what the user gets out of the first five minutes. That's not really how this product works.
I don't know why he spends time making recruitment creative. We have proven messaging doesn't matter, only frequency.
I don't know why he does user testing. We know in MS Teams messages if someone in the company doesn't like a feature in the app.
I find what's broken, name what's hidden, and deliver a direction the team can build on. That means running discovery, navigating stakeholders, and making the case for the right call — not the comfortable one.
I work best with companies building something that matters and ready to let evidence drive the roadmap. Series A startups, Fortune 500 enterprises, regulated industries, AI products — the environments change but the job doesn't: make sure the right thing gets built, in the right order, for the right reasons.
