Product

Definitions

Product-market fit
How much product satisfies strong market demand, i.e., target customers truly need and want the product.
Product-market fit (First Round Capital)
"A state of widespread demand for a product that satisfies a critical need and crucially can be delivered repeatably and efficiently to each customer".
North Star Metric
A single, primary metric that best captures the core value that a product delivers to customers.
Minimum viable product (MVP)
A product development strategy used to quickly get a basic version of a product into the market for initial testing and validation from real users.
XY Problem
Often in customer service - is where someone seeks help for a solution (X) they have chosen as a way to solve a different problem (Y). Helping with X won't help solve actual problem if it's not a good approach in the first place.
Project management vs. Product management
Project management is plan-driven (timelines, people tasked, execution plans), product management is user-driven (user adoption, customer satisfaction, business impact).

Goals

Build products that solve real user problems
Iterate based on continuous user feedback
Plan for market adoption from day one

Questions to Ask

Who is the target customer?

Without a clear target, you're designing for 'everyone', which ends up pleasing no one. Business-wise, vague targets equal wasted budget. Knowing your customer means targeted marketing, focused development, and a product that truly resonates. It's not just about who clicks, but who converts and becomes a loyal advocate. Bottom line: Know your audience to maximize impact and ROI.

What problem does your product solve?

Solve real problems, not imagined ones. Without a core value proposition, you're just wasting resources.

How does your product solve this problem?

Emphasize effective solutions, not just solutions. Ineffective solutions waste resources and erode trust.

Do you see product-market fit for your product?

UX strives for solutions that resonate with user needs. Business demands market validation for sustainable growth. Product-market fit isn't a 'maybe', it's a 'must-have'. It's about ensuring your product addresses a real market need, is competitively positioned, and has the potential for scale. No product-market fit, no sustainable business. It's that stark.

How will you measure the success of your product?

You need to know how you know you succeed or fail. If you can't measure it, you can't manage it, and you certainly can't improve it.

What is your go-to market plan?

Consider the user journey beyond the product itself, including reach, user acquisition, momentum.

What is a minimum viable product?

Conserve resources and minimize losses. Test early by putting your product in your users' hands as early as possible.

What is the development/iteration timeline for your product?

The shorter the timeline, the faster you can get feedback, the faster you can "fail fast".

What is the market size for your product?

Not all problems are worth solving. A problem that affects few people might not be worth your while.

Who are your competitors and how is your product different?

Understand user alternatives, identify gaps, opportunities, and your unique selling proposition (USP).

Are you replacing/refactoring for the sake of it? (common when trying to rewrite existing/legacy services in latest framework)

New is not better.

What were the surprises you had while coming up with this plan/prototype/product?

Learning from surprises is how we get smarter, faster, and more effective.

Have we engineered unambiguous "Short-Term Wins" (6-18 months)?

Most people won't stay on the "long march" unless they see compelling evidence that the journey is producing expected results quickly.

Alarm Bells

Get this feature added, I don’t care how you get it done.

No prioritization, no user research. Feature-driven, not problem-driven.

I’m doing this system revamp because I can shave X days from this process, though the entire process still takes 10X days in total from other manual processes and legacy systems.

You're optimizing the wrong bottleneck. The real problem is elsewhere.

I'm confident of rolling out my product to internal employee users... We don't do separate user research.

Internal employees are 'captive users'—they are forced to use the system and often know too much about how the organization works. They are rarely representative of actual public users, leading to skewed feedback.

The current system is dated. We will reach the max customization... go to the cloud, use Next JS, break up the monolith, and build common components.

Classic 'Second System Effect'. Justifying massive rewrites based on 'ugliness' rather than user value. Rewrites often fail because they underestimate hidden business logic.

I know the problem, I’m user number 1 and my colleagues are users 2, 3, 4…

No you (yall )are not representative of all users, no matter how experienced and frequently you use.

Users don’t appear to want to use our system, but we’ll write to their DSes and Dirs to encourage takeup.

Users aren't using it because it doesn't solve a real problem or the friction outweighs the value. No amount of executive pressure will fix this.

Users tell me they have this X problem and therefore need Y, so let’s just build Y.

This is the XY problem. We're focusing on the customer's attempted solution (Y) rather than the root problem (X).

Oh this insert govtech product? Not familiar with it but we know we need ours and they seem different anyway.

You're trying to recreate something that's presumably solved well. And doesn't seem like you did your competitive audit. Even if you're satisfied with your solution, you should say why yours works better, eg from user research.

Let's do UI UX better.

They're very different things! The person saying this betrays a lack of understanding of what these 2 acronyms mean. UI is a part of ux. UX is far more than just tinkering with screens, colors, typography, spacing on figma templates. And this lack of clarity prevents us from going into what needs to be solved and how we should solve them.

Everything's a native app, no matter if all you do is provide info (i.e. a static url or webapp is more fitting).

Over-engineered (too complex).

This is the XY problem. We're solving the wrong thing.

Fixing the wrong problem.

We need to hit these delivery timelines and requirements - that's what matters.

Process over value.

The data shows everything is fine, so those user complaints must be outliers.

Wrong metrics (users complain).

Dealbreakers

Red Flag
Product has no viable market, no users, no product-market fit.
Why

Nobody wants it.

Red Flag
Product solves only a small part of the problem or doesn't solve any real problem at all.
Why

Useless product.

Red Flag
Users don't like the product, don't use the product, but are forced to use it because of mandates or management pressure.
Why

Users hate it (forced).

Red Flag
Market has (new) alternatives, we either don't know or we hid our heads in the sand (insisting that ours is better).
Why

Outdated, better options exist.

Red Flag
Existing products that have no traction keep getting life support with no end in sight.
Why

Zombie product.

Red Flag
X product has Y% of weekly active users, never mind that these are captive users who are forced to use the platform.
Why

Fake user numbers (forced).

Red Flag
Are the gains marginal? We spend 10mil to cut one process by 2 days but overall process still takes 5 months because of other manual processes.
Why

Tiny gain, huge cost (pointless).

Red Flag
Building a product without an Organizational Change strategy.
Why

Great products fail if the org rejects them. (See Guide: Transformation).

Apptitude / Curated by Zixian Chen

© 2024–2026. All Rights Reserved.