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
- Make products that solve real problems for users
- If users keep asking why do I need this product and how do I use this, you've got a problem.
- A product is something that's useful to users, customers. Project management is a constituent, not its whole.
- Customer/user feedback makes its way back to change the product.
- Have a go-to market plan - public sector products should not get a free pass.
- If a product solves a real problem, people will want to join in, no matter how "bad" it seems to be (see: Twitch).
Questions
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.
What are the key features and benefits of your product?
Highlight value upfront - features are the 'what', benefits are the 'why' users should care. Focusing on benefits – time saved, money earned, efficiency boosted, stress reduced – speaks directly to user needs and business ROI. Ultimately, features sell products, benefits sell value.
What is the product vision?
Vision guide us to focus and alignment.
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.
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.**
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).
What is your go-to market plan?
Consider the user journey beyond the product itself, including reach, user acquisition, momentum.
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".
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.
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.
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.
Alarm Bells
They say...
Why I'd be scared
Get this feature added, I don’t care how you get it done.
There’s obviously no prioritization done for features and no idea (probably unlikely) it solves an important user pain point. User research is an afterthought, so this decision is definitely not going to help the product.
There’re 5 organizations using our wrapper product, they’re using it because doing this is cheaper than using the actual product as is.
We’re subsidizing this usage and wasting money (versus letting market economics dictate demand).
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.
The money spent on this new system is going to be wasted, because the crux of the problem lies in the majority of time wasted on manual processes and other legacy systems.
Get this feature added, I don’t care how you get it done.
There’s obviously no prioritization done for features and no idea (probably unlikely) it solves an important user pain point. User research is an afterthought, so this decision is definitely not going to help the product.
There’re 5 organizations using our wrapper product, they’re using it because doing this is cheaper than using the actual product as is.
We’re subsidizing this usage and wasting money (versus letting market economics dictate demand).
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.
The money spent on this new system is going to be wasted, because the crux of the problem lies in the majority of time wasted on manual processes and other legacy systems.
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 are not using it because it doesn’t solve a real problem or there’s just too much friction for too little value. If there’s a big problem, everyone will use it if it provides enough value. Obviously not the case here, and no amount of pleading senior leaders everywhere else will help.
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 wrong thing (customer’s attempted solution Y) rather than the root problem (X), which could be better solved with a new solution, Z. This is very common and I see this a lot.
Dealbreakers
Symptom
Why I'd be scared
Product is a suboptimal solution (read: XY problem)
Fixing the wrong problem.
Product solves only a small part of the problem or doesn't solve any real problem at all.
Useless product.
Product is managed as a project, with paper requirements and delivery timelines overriding questions on product value.
Process over value.
Product has no viable market, no users, no product-market fit.
Nobody wants it.
Users don't like the product, don't use the product, but are forced to use it because of mandates or management pressure.
Users hate it (forced).
Market has (new) alternatives, we either don't know or we hid our heads in the sand (insisting that ours is better).
Outdated; better options exist.
Existing products that have no traction, users keeps getting life support with no end in sight.
Zombie product (no end in sight).
X product has Y% of weekly active users, never mind that these are captive users who are forced to use the platform.
Fake user numbers (forced).
If user anecdotes are contradicting your data (that everything's alright), you might be measuring the wrong thing.
Wrong metrics (users complain).
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.
Tiny gain, huge cost (pointless).
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).