We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Customers' words and behavior diverge
Ravi Mehta's new essay opens with a focus group. When asked which app they'd use the next time they were single, nobody named Tinder, which was the largest dating app by far. Yet nearly everyone had met someone on it in the past year . One question asked people to imagine their future selves. The other asked what they had actually done . The real need was a better way to meet people. That is the need Hinge's "designed to be deleted" pitch speaks to .
His working definition of Voice of the Customer covers feedback "in all its forms," including support tickets, sales calls, app reviews and casual conversations. It aims at the job behind a feature request, not at customers designing your product. Research should change priorities and investment, not end up as a forgotten 200-slide readout .
On AI, he points two ways:
- Faster loops. One client runs 60-minute calls: 15 minutes exploring needs, a prototype built while the call continues, and the customer trying it in the last 15. That's a loop that used to take a six-week sprint . Interviews also build up a knowledge base that later questions can draw on, so a new question doesn't always need a new study .
- More distance. AI "can also put one more layer between us" and customers . PMs should check AI-generated conclusions against the underlying evidence .
The responsibility changes with level. Directors build reliable research practices. VPs and CPOs settle trade-offs between short-term results and long-term customer value .
When stakeholders expect LLM features to be 100% right
The pattern on r/ProductManagement: an owner sees a good demo, and then the first wrong answer becomes "the AI does not work" . The original poster's tactics:
- Agree an error budget in the stakeholder's own words, such as how many of 100 invoices a person can fix by hand.
- Measure the current manual process's error rate as the baseline.
- Sort errors by cost.
- Add cheap human review where mistakes are expensive.
- Show failures yourself before stakeholders find them .
What doesn't help, the poster says, is explaining how the model works .
The most practical reply suggests a pilot on a slice of real work. A person approves every output, and the team tracks the rate of outputs accepted unchanged. Agree in advance on the threshold for switching it on and the kind of mistake that shuts it off. That team brought "92% as-is over three weeks" to senior stakeholders . Another commenter keeps a repeatedly charted eval set on the tracking page, since accuracy varies between runs and between models .
What protects a product when features are cheap
Aakash Gupta uses Adobe as the case. It had no down revenue year from 2015 to 2025, and ARR is now $27.5B, yet its market cap fell from $311B to about $96B . His argument: features are "a few prompts" away, and agents weaken muscle memory as a moat . What can't be copied is learning. Firefly has generated 24B+ assets, which he calls 24 billion examples of what people ask for, and Adobe's AI-first ARR grew 150%+ last quarter . His test: write a one-page spec from your own public docs and give it to a coding agent. Whatever it rebuilds is table stakes .
An r/startups thread on the same question pushed back on easy answers. Stringing together public APIs isn't a moat . A funded entrant can catch up on 1.5 years of work once you've validated the market .
AI adoption is a team problem
Hiten Shah argues that most companies turned AI adoption into homework. A few employees became power users, but "almost none of that learning changed how the teams worked together." His conclusion: "The team has to be the unit of AI adoption" . Figma described its version as a "messy middle." Domain specialists build prototypes, and Figma wants PM-like functions in its CIO org to find what's working and build shared foundations for others to build on . Figma also says its embedded data scientists build as much or more product intuition than its PMs and engineers .
Also
- Agent UX. Paweł Huryn's Mini Harness is about 1,200 lines of Python. In his 10-task, five-run test, he places it in the top group with Claude Code but doesn't call it the winner . His PM lesson is that error messages are instructions to the agent, and "the words the agent reads are part of the product" .
- Agentic commerce. Stripe is hiring engineers and product people for agentic-commerce problems such as wallets, identity, risk, discovery and micropayments . Patrick Collison says "pretty much every part of the stack is going to change" .
For product discovery and prioritization, treat interpretations of user behavior and teammate intent as hypotheses rather than facts: Eyal says the checkerboard illusion persists after viewers learn squares A and B are the same color, because perception is shaped by predictive beliefs; he defines a belief as a conviction open to revision based on evidence. His Serena Williams anecdote illustrates a possible belief-framing effect, but with an important caveat: Eyal says her coach knowingly gave her a false claim about scoring 80% of the time at the net, and credits the changed belief with unlocking her performance. Treat this as an illustration, not a rationale for using false metrics with users or teams.
- Mini Harness is a roughly 1,200-line Python agent harness. On Terminal-Bench 2.0 it averaged 9.2/10 tasks with Claude Haiku 5.5 versus Claude Code’s 8.4, and 8.4 with DeepSeek V4.1 Flash, matching Claude Code; the evaluation used 10 tasks and five runs per harness, and the author cautions that the small gaps indicate a “top group,” not a clear winner.
- Building a custom harness is presented as a roughly 1–2-hour PM learning and portfolio exercise: the aim is to understand the building blocks, not merely use a finished harness.
- Treat tool instructions and error messages as agent UX: concise tool manuals and actionable errors help the agent choose its next step, and every tool call should receive a response—even when denied—because missing responses can break later requests.
- For reliable, lower-cost sessions, keep already-sent context unchanged and append new information; the article says rewriting it can disrupt the model’s reasoning and prompt caching. It gives Opus 5.5 cached-token pricing as $0.20 rather than $4 per million tokens.
- Treat exceptional founder heroics as a diagnostic, not a sustainable operating model: appreciate a one-off crunch, then investigate why it happened, why it was not anticipated, and how engineering leadership or processes can prevent a repeat. A company cannot reach its potential if the founder must continually rescue it.
- Build the early team deliberately: Walk looks at the first 20 hires as a signal of talent attracting talent, with a mix of talent hubs and people from outside the existing network, and constructive disagreement that can support growth from 20 to 100; he says he helps founders plan that team.
- Walk’s early-stage support model includes giving founders a point of view on product questions such as pricing and holding a substantive review of the company’s trajectory at least quarterly; as a Series A approaches, those conversations can help prepare the founder to lead formal board meetings.
- For enterprise AI strategy, the interview estimates 6–8 frontier or near-frontier offerings, with providers leapfrogging and sometimes only 3–6 months apart; models differ by capability, so enterprises can select among them rather than expect one model to lead on every dimension. It also says open-source models may lag 6–12 months, and points to private-data fine-tuning or building downstream products on AI models as alternatives to developing a frontier model.
- For AI-agent products, current coding systems are described as making human engineers roughly 3–5× more productive while people still review and architect the work; removing that human review in closed-loop systems is described as a riskier next phase. The discussion calls for robust engineering, hardened sandboxes, strong monitoring, and keeping cyber defense ahead of cyber attacks.
- AlphaFold is used by about 4 million researchers worldwide; the stated next expansion areas include biochemistry and predicting properties such as toxicity that matter to drug safety and efficacy.
- Customer research can mislead when it captures aspiration rather than behavior: in one focus group, nobody named Tinder as the app they would choose next time they were single, yet nearly everyone had used it in the prior year; the deeper need was a better way to meet people, not more time on the app.
- Voice of the Customer means combining sources such as support tickets, sales calls, app reviews, usability sessions, and conversations to uncover the job and motivation behind a feature request. Findings should change assumptions, priorities, or investment—not end as a research readout.
- AI can compress research: one client’s 60-minute call explores needs, builds a prototype during the conversation, and tests it with the customer; interviews can then become a shared knowledge base that teams query instead of repeatedly commissioning studies. But AI can add distance from customers, so PMs should check AI-generated conclusions against underlying evidence.
- The responsibility scales with seniority: PMs own understanding the customer problem and testing ideas; directors establish reliable research practices; executives represent customer needs in company-wide trade-offs.
- Test value before automating: One practitioner describes shipping an “AI” feature that routed a Slack message to an engineer for manual configuration, postponing automatic configuration until they knew whether the feature was valuable.
- Treat startup PM work as ownership: At a day-zero startup, expect to pitch, sell, handle customer service, or help raise money; also protect product direction from bolt-on features for every deal or poor market fit, and stay open to learning from cofounders.
- Optimize for startup speed, not process speed: One practitioner argues that moving faster can mean finding a different way to reach the goal, rather than executing the same process faster. Another cautions that perfectionism and an excessively high bar can slow startups, while advocating calculated risks rather than sloppiness.
- Check the company and role before joining: Ask whether the company has product-market fit, how it gets customers, and what your first six weeks or 90 days will focus on; one commenter describes mostly inbound acquisition as a good sign and mostly outbound as a struggle. One commenter also recommends getting salary and equity in writing, recounting a startup role with no salary, few sales, and no equity.
- Commenters report that “quick alignment” meetings can expand into 90-minute edge-case discussions, while a bug clarification turned into an exhausting two-hour conversation.
- PMs describe context-poor handoffs and workload strain: one inherited upset stakeholders’ issues without background; another was covering a former PM’s work and customer calls, developing strategy for two product lines, and learning a more complex product while engineering was overwhelmed.
- One PM says leadership SMEs delayed input for a year on requirements only they could provide, then asked the PM at the last minute to define requirements for data the SMEs owned.
Treat AI adoption as a team-level workflow change, not individual homework: a CEO mandate can lead to uneven employee learning while individual gains fail to change how teams work; Hiten argues the team should be the unit of adoption. The quoted post adds that security, proprietary data, and access can slow enterprise implementation despite executive pressure to adopt AI.
- For website discovery, ask the teammate who talks to customers every day what they would change; Shah expects them to have an answer.
- Shah’s planned “Coding Agents 101” session is aimed at people who have never coded and uses examples from his own site to demonstrate how to get started and understand the work.
Hiten Shah announced a live Coding Agents 101 session for people who don’t code, using examples from his website to demonstrate Claude Code or Codex and how to judge whether an agent’s output is worth keeping.
A QA engineer with 4.5 years in B2B SaaS is pursuing AI PM through hands-on building after finding a traditional PM program unhelpful: they co-founded a stealth AI research tool and own product, specs, and solution design; build AI developer side projects; and work on AI-assisted QA automation. Their project work includes Graph RAG, multi-agent workflows, and LLM evaluations. They ask whether this portfolio can outweigh formal training or certifications, count as PM experience rather than QA, and how to make it convincing to AI-PM hiring managers.
One PM-track job seeker reported that after reaching APM/PM final rounds and receiving an offer later rescinded over budget changes, their search had slowed to about 2–3 callbacks a month; they were considering expanding into solutions consulting and implementation roles .
Hiten Shah gave Claude Code and Codex different jobs on the same 404 page: one small change and one aimed at helping visitors find their way after an error. He plans to show the work and explain what he checked before accepting the results, offering a practical example of evaluating coding-agent output against user needs and acceptance criteria.
- Set expectations in operational terms: agree on an error budget, measure the current manual process as a baseline, distinguish mistakes by cost, add human review where errors are costly, and surface failures early.
- Validate with a human-reviewed golden evaluation set and repeated tests, since accuracy can vary across runs and models. For rollout, pilot on a slice of real work with every output reviewed; agree in advance on the acceptance threshold and errors that stop the pilot. One commenter reported 92% of outputs accepted unchanged over three weeks, and said a low rate can prompt a scope change before full rollout.
Noats offers bot-free meeting recording on Mac, with local transcription, speaker separation, note generation and transcript-grounded Q&A; local processing is the default, with an option to connect frontier AI, and the product is free during beta. The team says it built Noats in a month, then waited more than a year for local AI to catch up; it describes the meeting-notetaker category as having expanded amid Granola and Wispr Flow launches and Superhuman’s acquisition of Fathom.
A Reddit post reports that Simple Organic’s new AI skin scan returned different results when the author ran it twice seconds apart, raising a product-consistency concern for the AI feature.
- Adobe reported no year of falling revenue from 2015–2025 and reached $27.5B ARR, while its market cap fell from $311B to about $96B. Gupta’s product-strategy lesson is that AI agents make features and learned interface habits easier to displace; distinctive context and accumulated learning are stronger potential defenses.
- Adobe Firefly users generated over 24B images and assets since its 2023 launch, creating examples of user requests that clones cannot copy; Adobe’s AI-first ARR grew more than 150% last quarter.
- A practical moat test for PMs: give a coding agent a one-page spec derived from your public docs; treat what it can rebuild as table stakes and focus effort on what it cannot reproduce.
- Aakash Gupta reports that James McAulay reached £100K/month in 95 days with Claude Code and no team, versus six years for his previous business. McAulay’s growth system used a mission file to keep work aligned to a goal, an experiment file recording baseline and target before launch, and a weekly Friday retro to review metrics and compounding.
- In a mock FDE case, Priya first clarifies the desired outcomes, timeline, and budget, then recommends using city data and firsthand input from people experiencing homelessness and service providers to identify the biggest entry or re-entry bottlenecks and where intervention could change outcomes.
- She argues for measuring outcomes rather than activity—for example, post-treatment stability instead of admissions and employment retention instead of training completion—and piloting with a defined population to track whether homelessness entry or re-entry falls and adjust accordingly.
A commenter cautioned that $70/hour may be high for a newly onboarded Toptal PM, who may first need to secure work and build profile reviews; this is an anecdotal view, not a confirmed rate benchmark.
For learning AI evals, one practitioner says Teresa Torres’s interview and writing made the topic click . Another found reviewing 100 of their own outputs and recording what was wrong more useful than taking a course . A different commenter argues that evals can be approached as a prompt-and-answer database plus random safety tests, and that asking AI may be more up to date than following one individual .
Voice of the Customer.
On an impossibly sunny day in Los Angeles, I sat in a loft in Venice observing a group of twenty-somethings talk about their dating lives. The focus group moderator asked, “Next time you’re single, which app will you use to meet someone?” Not one person mentioned Tinder. How could that be? At the time, Tinder was the largest dating app — by a large margin.
Later in the conversation, the moderator asked, “Have you met anyone on Tinder in the last year?” Nearly everyone raised their hand.
Top 1% Builder with Ravi is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
Same people. Same app. Two very different answers.
The first question asked people to imagine their future selves. The second asked them to recall what they had actually done. If we’d stopped after the first answer, we could have walked away with a confident conclusion that was spectacularly wrong.
That’s the tricky thing about customer research. You can talk to the right people and still learn the wrong lesson.
But the answer isn’t to stop asking. It’s to get better at understanding the people we build for — what they do, what they need, and where their words and behavior diverge.
AI makes it easier to collect and summarize what customers say. It can also put one more layer between us and the people saying it.
The goal is not to collect more feedback. It is to understand your customers well enough to make better decisions.
That brings us to Voice of the Customer, the fifth of the 12 competencies essential for building remarkable products.

Voice of the Customer is the second of three Customer Insight competencies, alongside Fluency with Data and User Experience Design.
Join the Top 1% Builder Series
The Top 1% Builder Series is a free 12-part live workshop series (one week per competency) with Ravi for product managers, leaders, founders, designers, engineers, and builders who want to ship products customers love — with AI amplifying the judgment they already have. Live attendance is free. On Friday, November 6, we’ll dive into Voice of the Customer at 9 a.m. PT / noon ET. Replays and slides are available to paid Top 1% Builder Club members.
How to build remarkable products

The 12 competencies necessary to build remarkable products
Last week, we explored Fluency with Data (opens in new tab) — moving beyond reporting to understand what drives customer behavior and business outcomes. Data can tell us what people are doing. Customer research helps explain why.
The Product Competency Toolkit organizes the work of building remarkable products into 12 competencies across four areas:
Product Execution — getting the right product built well
Customer Insight — understanding the people you build for
Product Strategy — choosing the outcomes that matter
Influencing People — rallying people around the org to make it so
Voice of the Customer sits within Customer Insight. Three competencies work together:
Fluency with Data — turning evidence into an understanding of customer behavior and the levers that drive outcomes
Voice of the Customer — staying close to customers to learn from their needs and underlying motivations
User Experience Design — making it easy for people and agents to access the product’s value

Customer Insight is the ability to understand customer behavior, needs, and experiences well enough to make better decisions.
These are connected ways of understanding customers, not isolated skills. A pattern in the data might raise a question for customers. A conversation might explain a trend on your dashboard. A prototype can help you close the loop — have you identified the right problem and solved it the right way?
Voice of the Customer, defined
Voice of the Customer is the ability to use customer feedback in all its forms — from casual conversations to formal studies — to understand customer needs and behavior, make better product decisions, and drive meaningful business outcomes.
Each element of that definition is chosen carefully:
Customer feedback in all its forms. Research isn’t limited to focus groups or surveys. Support tickets, sales calls, app reviews, usability sessions, diary studies, community discussions, and casual conversations each reveal something different. The best product builders build relationships with their customers, talk to them nearly every day, and draw on those sources to build a fuller picture.
Understand customer needs and behavior. Good customer research goes beyond asking customers what they want. The goal is to understand what’s underneath a feature request: What’s the job they’re trying to accomplish? Why does it matter to them? How do they solve it today? What could we do better for them? Don’t ask customers to design your product. Understand them well enough to design what they need.
Make better decisions and drive meaningful outcomes. Too often, I’ve sat through a fascinating user research readout, only to watch the 200-slide deck disappear from everyone’s mind as we leave the room. Customer understanding must change what the team does: challenge assumptions, shape priorities, and shift investment toward what customers need.

A feature request is where the conversation starts. Understand the job underneath it well enough to design what the customer actually needs.
Over my career, I’ve seen a pattern: companies often start out strong at Voice of the Customer. In those early days, there isn’t much data, so you have no choice but to talk to customers. Founders answer support emails. PMs join customer calls. People building the product hear firsthand when it disappoints someone.
As the company grows, that closeness can disappear. Feedback passes from person to person in a game of telephone. Conversations turn into reports. Those reports become a few bullets in a quarterly presentation.

As a company grows, feedback passes from person to person. Conversations turn into reports, and reports become a few bullets in a quarterly presentation.
Meanwhile, the company’s questions take over: How do we increase retention? How do we hit the revenue target?
Those are important questions. But they can crowd out a more useful one: What do customers need from our product?
Without that understanding, customers become cells in a petri dish. We poke and prod them with experiments, hoping to produce the behavior our business needs.

Without real understanding, customers become cells in a petri dish. We poke and prod them with experiments, hoping to produce the behavior our business needs.
We can become remarkably sophisticated at measuring people we no longer understand.
How Voice of the Customer evolves with AI
Some of the most revealing moments of my career came from design sprints. Customer research was slow and expensive. It was worth it.
The classic sprint takes five days, with one day to build a realistic prototype. At Tinder, Tripadvisor, and with clients, I used a “mega sprint”: six weeks to explore a problem, test solutions with customers, and share what we learned.
The prototype alone could take a full squad two or three weeks. Even then, we stitched together clickable screens — more Wizard of Oz than working software — and hoped customers wouldn’t stray off the path. Remember those flashing blue boxes showing you where to click?
When it worked, the signal was gold. Watching a customer use the prototype could change our understanding in minutes.
But you had to be in the room.
Everyone else got a deck. Someone combed through hours of recordings and notes to explain what we’d witnessed. Too often, the findings never made it beyond the readout.
AI is changing both parts of that process.

As companies grow, data starts to stand in for talking to customers. With AI, you can bring the customer into every decision.
From six weeks to sixty minutes
A client I work with now runs 60-minute research calls. The team spends the first 15 minutes exploring the customer’s needs, builds a prototype as the conversation continues, and has the customer try it in the last 15 minutes.
A loop that took six weeks can now happen in one conversation.

A mega sprint took six weeks to explore a problem, test solutions with customers and share what we learned. That loop can now happen in one 60-minute conversation.
The prototype is better, too. Working software creates a suspension of disbelief: customers stop imagining the product and start using it. The team can explore a need and test a possible solution before the call ends.
From a readout to a shared memory
Every interview becomes part of a growing knowledge base. Anyone in the organization can ask questions of those conversations instead of hunting through a 200-slide deck. A new question doesn’t always require a new study. The answer may be in last month’s interviews.

Every interview becomes part of a growing knowledge base. A new question doesn’t always need a new study, because the answer may be in last month’s interviews.
Voice of the Customer may be one of the areas of product work AI changes most. Working prototypes give customers something real to respond to. A shared knowledge base keeps those conversations useful long after they end.
What we learn in one room can now shape decisions across the company.
How it feels to master Voice of the Customer
When you master Voice of the Customer, you become the customer’s advocate on your team. Customers cannot attend roadmap, strategy, and goal-setting meetings, so you bring the customer into the room. You translate what you learn into clear context that helps humans and agents understand and empathize with the customer.
You use a portfolio of research methods to explore the customer’s perspective. You know when to have a deep conversation, run a survey, observe a customer using a prototype, review session replays, or analyze feedback at scale. You also build strong relationships with people who speak with customers every day, including customer support, sales, and forward-deployed teams.

Mastering Voice of the Customer means choosing from a portfolio of research methods, based on what you need to learn.
Most importantly, what you learn shapes what your team builds. You uncover needs, motivations, and points of friction, then use that understanding to give your team direction.
Voice of the Customer from APM to CPO

Voice of the Customer is relevant at every level, but the scope evolves as you get more senior.
Every competency matters at every level. A CPO may not test the product personally, but still builds the culture and systems that protect Product Quality (opens in new tab). The responsibility remains; the scope changes:
Product managers build products.
Product leaders build the teams that build products.
Product executives build the systems that build the teams that build products.
We can apply the same framework to Voice of the Customer.

Voice of the Customer expectations by level, from learning when customer feedback would improve a decision to putting the customer first in the company’s hardest trade-offs.
As an APM, you learn to recognize when customer feedback would improve a decision. You practice asking questions without leading, choose relevant participants with support, and turn what you learn into a clear recommendation. You learn from research partners and customer-facing teams instead of assuming every study must be yours to run alone.
As a PM, you take ownership of understanding the customer problem. You maintain direct relationships, choose research methods that fit the question, and combine what customers tell you with what the data shows. You use prototypes to test ideas before committing to them and check AI-generated conclusions against the underlying evidence.
Senior and Principal PMs use that understanding to shape direction. You distinguish a one-off feature request from an important unmet need, reconcile conflicting evidence, and judge when to investigate further or make the call. As a Principal PM, you may uncover a customer problem that spans several teams or requires a complex solution.
When you manage PMs, you help them develop that judgment — when and how to ask the right questions. You encourage your team to uncover needs, nurture customer relationships, and gather firsthand evidence for decisions. You make sure teams have access to customers and the resources to conduct research. Your job is to build their curiosity and skill, not become the only person who talks to customers.
At Director and Senior Director levels, you make customer understanding part of how the organization operates. You establish reliable research practices, connect findings across teams, and make customer evidence a consistent part of major investment decisions. You help teams stay close to customers as the organization grows more complicated.
At the executive level — VP or CPO — you represent customer needs throughout the company. You resolve trade-offs between short-term business results and long-term customer value. You justify the investment needed to keep the organization close to customers and stay close yourself. You put the customer first — especially when it’s hard, especially when it goes against the grain.
You create a culture of customer obsession.

The emphasis of Voice of the Customer shifts with seniority. Research planning and skills start at APM, direct relationships and solution testing start at PM, and access, standards, and culture become leadership responsibilities.
Back in that loft in Venice, people weren’t contradicting themselves. They used Tinder. They wished they didn’t have to. They were tired of swiping and wanted a better way to meet someone.
Hinge’s promise — an app “designed to be deleted” — speaks directly to that need. Encouraging users to delete your app might seem like bad business. But people don’t come to a dating app to stay on a dating app.
The best companies listen for that deeper need — and build around it. They create value for customers first. Only then do they capture value for themselves.

People in that loft weren’t contradicting themselves. They used Tinder, and they wished they didn’t have to. The best companies listen for that deeper need and build around it.
Next week: User Experience Design — clearing the path to your product’s value.
Dive deeper into Voice of the Customer
The free Product Competency Toolkit dives deep into the 12 competencies that turn good product builders into remarkable ones. Updated entirely for the AI era, it explains how each competency is evolving — whether you want to improve your own craft, coach your team, or help your entire organization level up.
It’s for anyone building products across product, design, engineering, marketing, leadership, or a venture of their own.
Top 1% Builder with Ravi is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
- Customer research can mislead when it captures aspiration rather than behavior: in one focus group, nobody named Tinder as the app they would choose next time they were single, yet nearly everyone had used it in the prior year; the deeper need was a better way to meet people, not more time on the app.
- Voice of the Customer means combining sources such as support tickets, sales calls, app reviews, usability sessions, and conversations to uncover the job and motivation behind a feature request. Findings should change assumptions, priorities, or investment—not end as a research readout.
- AI can compress research: one client’s 60-minute call explores needs, builds a prototype during the conversation, and tests it with the customer; interviews can then become a shared knowledge base that teams query instead of repeatedly commissioning studies. But AI can add distance from customers, so PMs should check AI-generated conclusions against underlying evidence.
- The responsibility scales with seniority: PMs own understanding the customer problem and testing ideas; directors establish reliable research practices; executives represent customer needs in company-wide trade-offs.