Skip to content
Search

Product

lastmod 2026-07-16created 2025-01-2825 edits

A product (製品) is a good made through a manufacturing process. For companies engaged in manufacturing, it is the main item they sell. Some products go through a manufacturing process but have no physical form. Music albums, videos, and software that can be delivered in digital form over networks such as the Internet fall into this category.

In corporate accounting, a product means only goods that have gone through a manufacturing process, which makes it a concept contrasted with merchandise. In corporate accounting, merchandise means goods that have not gone through a manufacturing process. For example, if you make watches yourself and sell them, they are products, but if you buy watches from a supplier and sell them, they are merchandise.

How consumer psychology informs AI product design

AI product interfaces are too complex for ordinary users -> growing need for user-friendly, intuitive interfaces

Applying user psychology (the IKEA effect, the paradox of choice, the bandwagon effect, the soownership effect, the foot-in-the-door technique) to AI

The IKEA effect : The IKEA Effect

  • The IKEA effect is the phenomenon where users value a product more highly when they take part in making it
  • This is similar to the egg theory, but there is a difference
    • Egg theory: if the process is too easy, users don't feel they contributed
    • IKEA effect: users value it more because they made it themselves
  • Implications for AI product design
    • AI products should emphasize personalization
    • AI assistants, chatbots, etc. that users can set up and customize themselves can deliver higher satisfaction
    • e.g. if an email management AI can be configured to match the user's style, the user will find it more valuable

The paradox of choice : The Paradox of Choice

  • Too many options cause anxiety, choice paralysis, and dissatisfaction
    • In a 2000 study, 30% bought when offered 6 jams, but only 3% bought when offered 24 jams
    • The more options there are, the harder it actually becomes for users to decide
  • Problems in AI products
    • Current AI products offer too many options, confusing users
    • e.g. Gemini's model selection UI is too complex and hurts the user experience
    • A feature that automatically picks the best model is needed
  • Examples of well-designed AI products
    • Midjourney: one prompt, one image model, 4 results → simple and intuitive
    • Granola: a meeting summary AI with a clean UI that needs only minimal user input
  • AI should reduce the user's burden and provide an intuitive experience
    • Rather than excessive features and settings, it matters to design so users can easily do the task they want

The bandwagon effect : The Bandwagon Effect

  • Bandwagon effect: the psychological phenomenon where people copy what others are doing
    • e.g. TikTok dances, the skinny jeans trend, the ALS Ice Bucket Challenge, etc.
    • In startups, it drives viral growth and network effects
  • Problems in AI products
    • Most current AI products lack social features, so users have to explore on their own
    • e.g. ChatGPT lacks network features that let users share
    • There is an active culture of sharing ChatGPT prompts on TikTok, but no feature officially supports it
  • Image generation models need improvement too
    • Midjourney's "Explore" feature lets you see popular images, but lacks a way to see content created by your friends or network
  • AI is currently in a "single-player" state
    • More network-based and collaboration features are likely to be added going forward
    • It should be designed so users can share information more easily and extend the AI experience into a social setting

The endowment effect : The Endowment Effect

  • Endowment effect: the psychological phenomenon where people value things they own more than their actual worth
    • In a 1990 study, when people were randomly given a mug or pen and then offered a chance to trade,
    • they tended to value the item they owned more highly
  • Implications for AI products: the importance of personalization
    • The more users configure things themselves and build up a personalized experience, the more attached they become to the product
    • e.g. once an email AI learns the user's style, it becomes hard to give up
    • If Granola reflects user feedback to provide tailored summaries, users will find the product more valuable
    • Emotional AI (e.g. NSFW chatbots) also becomes harder to replace as the personal connection with the user deepens
  • Good AI design should give the feeling that "this product is just for me"
    • The more AI learns from user data to deliver a personalized experience, the more loyalty grows
    • To maximize the endowment effect, AI products should be designed to become increasingly optimized for the user

The foot-in-the-door technique : The Foot-in-the-Door Technique

  • Foot-in-the-door technique: a psychological strategy of getting someone to accept a small request first, then gradually leading them to accept bigger ones
    • In a 1966 study, people who put a small "Drive Carefully" sign in front of their house
    • agreed more readily two weeks later to a request to install a larger billboard
    • Widely used by companies, e.g. free trial → paid subscription conversion
  • Applications in AI products
    • Most AI services use a freemium model, encouraging payment after a free trial
    • For AI to drive new usage behavior, it works well to offer small features first and expand gradually
  • Legal AI example
    • If a legal AI automates all work from the start, the conservative legal industry may push back hard
    • So early on it should help with simple tasks like contract review,
    • and once users are comfortable, expand to more powerful features like drafting documents
  • AI products should naturally lead users toward more powerful features
    • Offer low-commitment features early → it matters to design so users gradually make deeper use of it

Final thoughts: the problem of growing complexity

  • Current AI products are too complex
    • Product teams tend to show off every feature and possibility of AI
    • But restrained design delivers a better user experience
  • The line between consumer and enterprise is blurring
    • e.g. Cursor, ElevenLabs, Elicit, GPTZero, Granola, HeyGen, Midjourney, Perplexity, Runway, Suno, etc.
    • are adopted in both consumer and enterprise markets
    • However, many AI products feel like enterprise tools and lack consumer-friendly design
  • Core principles of AI product design
    • Users want simple products: an intuitive experience matters more than too many options
    • Explain features clearly: design so users can easily understand which features they can use
    • Lead users to expand their use naturally: design so they can gradually use more powerful features
  • Conclusion
    • AI products should provide a consumer-centered, intuitive experience
    • It matters to reduce complexity, emphasize core features, and design so users adapt naturally

Why everyone loves it but nobody buys it

  • Why everyone loves it but nobody buys it | GeekNews
  • Product Purgatory
    • When you introduce a product, many people praise it but say things that put off buying
    • Founders often mistake this positive feedback for actual product validation
    • But in reality, even when customers genuinely like it, they frequently end up not buying
    • The situation where users like a product but don't buy it is exactly Product Purgatory
  • The Magic Wand test: a way to check whether real demand exists
    • Assume you offer the product completely free, with every issue such as installation, training, and security already solved
    • Even under these conditions, people often answer "no"
    • This means that even if the product delivers real value, the burden of risk, time, and change outweighs that value
    • For example, there was a startup that prevented confidential email leaks, but it failed because of the risk of placing a new company at the center of the email system
    • Customers consider buying only if the value the product delivers is far greater than the 'cost of adoption'
  • When it passes the Magic Wand Test but still doesn't sell
    • The product passes the Magic Wand Test, and customers really like it, but purchases still don't happen
    • The reason is that there is no reason to adopt it now, i.e. no Urgency
    • Customers always have 1–3 top priorities, and the product sits outside those priorities
    • For example, website accessibility is valuable and customers acknowledge it, but in most cases it is around priority #8
    • A product that doesn't make it into the priorities gets postponed no matter how good it is
  • How to escape purgatory: find customers who need it now
    • The answer is not "is it valuable?" but finding "who needs it right now"
    • Taking 'accessibility' as an example, for a company building a strategy to win government contracts, accessibility becomes priority #1–3
    • Define the customers who meet the conditions for needing it right now, and adjust marketing and the product to fit them
    • The key is narrowing the product's marketing target to "...and who need it right now"
  • Questions for identifying urgency
    • Is this strategy directly tied to the company's revenue? : regulatory compliance, industry certification, announced strategy, market entry, M&A, etc.
    • What crisis triggers a purchase? : lawsuits, executive changes, PR incidents, negative analyst reviews, competitor attacks, etc.
    • What competitive pressure creates urgency? : competitor feature launches, market share gains, technology shifts, etc.
    • What financial conditions raise urgency? : budget exhaustion, changed expectations after fundraising, forming a new team, etc.
    • How can you find customers with these conditions? : CEO statements, customer complaint reviews, public strategy changes, new hiring, industry reports, regulatory changes, etc.

Conclusion: only by narrowing your customers does the path appear

  • No product is always useful, always risky, or always a priority
  • So you can escape purgatory only by finding the customer segment that needs the product right now
  • If that segment is too small, hard to find, has no budget, or is blocked for other reasons, the product's very sustainability is shaken
  • But even starting from a small target, a spread effect can be expected, and a focused strategy can produce results

A field guide to rapidly improving AI products

Successful AI teams focus on measurement, iteration, and learning rather than complex tools

6 principles to practice:

  • Look at the data yourself and run error analysis
  • Build simple, efficient tools to support iterative learning
  • Involve domain experts and empower them
  • Bootstrap the initial evaluation system with synthetic data
  • Maintain trust with binary evaluation + critiques + alignment checks
  • Run the roadmap based on number of experiments, not features

Beyond the AI MVP: what you actually need

See Intelligent agent#Beyond the AI MVP: what you actually need.

The 28 AI tools I wish existed

50 lessons learned building successful products at PostHog

  1. Small teams (6 people or fewer) can build great products, but they must be given full autonomy: setting goals, prioritizing the roadmap, choosing metrics, talking to users, shipping code fast, and so on.
  2. A product's success depends on the people who build it. Keeping the hiring bar high is key, because talent compounds. A bad hire slows a team down more than any other factor.
  3. Trust is essential to building great products. Lack of trust is one of a team's biggest bottlenecks, and it usually results from hiring below-par people or not giving them proper feedback to improve.
  4. Trust is also built through transparency. Work in public, hold discussions in the open, and document your work. This way everyone shares the context they need, and you eliminate the political fights that happen at many companies.
  5. Rely on trust and feedback, not process. This is one of our core values. Building and growing something people want is a subtle problem, so we trust our employees' judgment. When things go wrong, we give direct feedback.​
  6. Leadership shares company goals, and product teams (engineers) decide what to build to reach them and set their own goals. Both sides should review the actual impact with metrics and user feedback.
  7. A product is subordinate to its ideal customer profile (ICP). The ICP is who you build for and the most important factor in deciding what to build. An accurate ICP defines not only the target customer but every aspect of the product and go-to-market strategy.
  8. To find your ICP, guess first and then test. Ask questions at signup, compare retention, identify power users, and run NPS surveys. As information and confidence accumulate, add detail.
  9. Create product principles. Ours are "provide every tool needed to evaluate success, get in first, and be the source of truth for customer and product data." This gives a common language for discussing ideas and making decisions.
  10. Map out everything users might want. You need this when prioritizing the roadmap. This way you won't miss great ideas beyond the horizon.
  11. A product is more than its features. It is the brand and the product experience it gives others. How much you invest in each feature, who you hire, build decisions, lead features, customer communication, and pricing all create its uniqueness.
  12. Your website is the product's first impression. A boring, template-like site signals that the product and team behind it are weak. Building your own distinctive site tailored to your ideal customer profile prevents this and drives user acquisition.
  13. Sometimes it's not a product problem but a market problem. For example, when Tom Blomfield, Monzo founder and YC partner, was building a bill-splitting service for college friends, he was advised to stop building and focus on getting users. When he got one user after 4 weeks of cold calling, he knew it was time to pivot.
  14. If you pivot, do it big. Stewart Butterfield turned two game companies into Flickr and Slack. LinkedIn co-founder Reid Hoffman says startup founders must 'slash and burn' the rest of the business to pivot from failure to success. If it looks similar, go further.
  15. As Jason Fried of 37signals says, "You can't validate an idea. It doesn't exist, so you have to actually build it. The market will validate it."
  16. Plans are useful but not to be followed strictly. Good execution is not carrying out a specific plan but repeatedly doing the most important thing. Judge people by what they ship, how often they ship, and the impact, not by whether they "stuck to the plan".
  17. Delaying something "just one more week" is almost always a bad idea. Over a few months, this attitude adds up to a huge loss of momentum. The sooner it's in users' hands, the sooner you can learn its value and improve it.
  18. Reduce work in progress. PRs should be finished within a day, start your day by responding to others' review requests, and merge anytime, ship behind feature flags, and test in production. All of this reduces the burden of work context.
  19. Shipping fast is at the core of our product development philosophy, but it has trade-offs. Technology procurement, planning meetings, agile rituals, and metric reviews take a back seat. Asynchronous work makes this more feasible.
  20. Introduce new technology into the product only for pressing problems such as excessive cost, scaling issues, or customer demands. You can find the solution by asking how your team or another team solved it themselves.
  21. Artificial deadlines don't make teams faster. Instead, they cause a doom loop leading to mountains of tech debt and burnout. Remove processes that slow teams down and give small teams the autonomy to ship fast.
  22. Another way to ship faster is to eliminate default design. Get a design system running, then let engineers build. When needed, polish what has already shipped through design review.
  23. Feature flags let product engineers ship changes quickly, test in production, and get real user feedback. They also reduce risk by acting as a kill switch when something doesn't work as expected.
  24. At PostHog, the best communication is a pull request. Unlike messages or issues, it turns feedback into impact immediately. It fits a bias for action and creates a tighter feedback loop.
  25. Make ownership clear. Deciding what to build becomes much clearer and faster. Teams that avoid ownership waste time on planning, brainstorming, meetings, and project management instead of shipping.
  26. Engineers are capable of deciding what to build. They understand technical constraints, recognize feature patterns, and know how to solve problems. However, there can be an information bottleneck about user needs.
  27. Instead of controlling engineers, product managers should provide context to product teams through product analytics, user research, competitor research, and so on.
  28. Most of us are not Steve Jobs. We don't have the vision to build 'on our own' from the start, nor do we paint the big picture. Instead we ship, give it to users, and iterate on feedback. The faster this goes, the better the product gets.
  29. Hire and rely on product engineers. They combine the full-stack skills and customer obsession needed to build products. They should do everything from talking to users, interviews, recruiting for new feature tests, collecting feedback, handling support, to incident response.
  30. Read The Mom Test. It teaches how to talk with potential users about their problems. The key is two types of user interviews: problem exploration and solution validation. The former guides future product decisions, and the latter helps improve current work.
  31. To get the most out of user interviews, figure out in advance who your users (ICP) are, how they use the product, and what you'll build next. This way the interview sharpens the focus of the next step instead of causing confusion.
  32. Among potential things to build, support requests are the most 'real'. A specific user is facing a concrete problem, so solving it improves the product immediately. Other changes are not this straightforward.
  33. Having engineers handle support encourages ownership of the whole product lifecycle, from ideation to implementation to ongoing maintenance. Each stage builds context on real customer pain points and the code behind issues, linking them together.
  34. Engineers handling support shortens the loop between user problems and shipped fixes. Support staff, product managers, and planning processes don't get in the way. As a bonus, users love it.
  35. Korean: 자사 제품 사용 (dogfooding) helps speed up shipping, catch problems before they reach users, understand the product deeply, and build empathy with users. However, it doesn't replace talking to users, real feedback, or tracking usage metrics.
  36. Just as our product team solved its own need with interview pop-ups, solving your own needs is effective for validating use cases. If you should be using your own product but aren't, it's a sign something is wrong, so fix it.
  37. Great product builders are always prototyping and experimenting. They must be comfortable building MVPs and proofs of concept, shipping unfinished work, taking in feedback, and pivoting when they fail. They also need every skill to go from zero to build, from infrastructure to design.
  38. A successful A/B test requires a good hypothesis explaining what is being tested and why. Include the test context, the changes, the metrics, and the expected results.
  39. When experimenting with a product, know that it may fail and be removed. Set it up for easy removal with feature flags, and ship a 'good enough' version instead of a perfectly maintained, scalable version. You can improve it once it succeeds.
  40. Product experiments can be much 'dumber' than you think. Instead of building the full feature, try a fake door test. You add an option or button that does nothing and see whether people click it.
  41. A failed product experiment is not the end of the world. At Google, 80–90% of experiments 'fail'. It may look like a waste of time, but at scale the 10% that succeed offset all the failures. Like the A/B test of Bing's headline display, which raised revenue by 12% (over $100 million).
  42. When focusing on growth, think and prioritize like a growth engineer. Identify target areas, pick representative metrics, form improvement hypotheses, and implement tests with the smallest possible experiments.
  43. Adopting analytics is almost never too early. It's fine for pre-launch products, but launching without analytics because it's "too early" is a false economy. After launch, the priority shifts from shipping at maximum speed to shipping 'the right thing' at maximum speed.
  44. When starting analytics, start small. Pick a specific product or feature, track usage with autocapture, visualize it with trend and retention graphs, and try shipping features that improve them. The "modern data stack industrial complex" makes it look more complicated than it is.
  45. If you don't know which metric to start with, we recommend activation. It sits above other metrics, engineers directly influence it, and it is useful across the whole organization.
  46. Besides activation, retention is another key metric for understanding the impact of what you build. Tracking weekly changes lets you gauge whether changes help retain users.
  47. When measuring product-market fit, check whether user engagement grows exponentially faster than user growth and whether retention flattens out (above 0%). Then look at whether ICP users retain well and whether paying customers belong to the ICP.
  48. Growth reviews check whether what the team builds affects important metrics such as revenue, product analytics, and user feedback. At PostHog, this is a key responsibility of product managers.
  49. When building multiple products, treat each product like a mini startup. Its own product decisions, pricing, revenue, costs, and coordination with customer-facing teams.
  50. Stick with products you find interesting. As PostHog co-founder James wrote in his product-market fit guide: "If it's not interesting, pivot. That's all there is to it. You get bigger results when you stick with work that feels like your own.".

See also

Favorite site

author Zer0 sitemap