We see an opportunity. Do we need a new product?
Maybe. But “new product” shouldn’t be the starting point.
Organizations naturally get excited about building something new. A competitor launches a product. Customers ask for a feature. Growth slows. A vendor demonstrates a new capability. Someone sees an opportunity in the market.
Before creating another product, determine whether the opportunity actually requires one.
Sometimes the right answer is new.
Sometimes the better answer is fixing what you already have.
Start with the problem you are trying to solve
Don’t start with the product.
Start with the customer or business problem.
- What is happening today that shouldn’t be happening?
- What isn’t happening that should be?
- Who has the problem?
- How significant is it?
- What evidence tells you the problem actually exists?
“We need a new checking account” isn’t a problem statement.
“We are losing operating-account relationships among businesses that need capabilities our current product doesn’t support” is much closer.
The distinction matters because the second statement leaves open several possible solutions.
The first has already chosen one.
Make sure the existing product is actually the problem
A product can underperform for reasons that have little to do with its fundamental design.
Pricing may be wrong.
The target market may be unclear.
Employees may not understand when to recommend it.
The digital application may create unnecessary abandonment.
Operational requirements may make the product difficult to open or service.
Marketing may be attracting customers who don’t fit the intended economics.
Or the product may have accumulated enough exceptions and workarounds that nobody is quite sure what the standard product is anymore.
Building something new doesn’t automatically fix any of those problems.
In some cases, it simply gives you two products with the same underlying problem.
Look for unused value in what you already have
Before adding something to the product set, understand what the existing products can already do.
There may be features customers don’t know about.
Capabilities may exist in the core, digital platform, processor, or another vendor relationship that were never fully implemented.
Pricing options may exist but be poorly positioned.
A product designed years ago for one segment may have capabilities that can serve another with relatively modest changes.
Organizations sometimes pay for technology they haven’t fully deployed while simultaneously evaluating another vendor to provide a capability they effectively already own.
Inventory before you invent.
Know what a new product really costs
The cost of a new product is not the cost of configuring it in the system.
There are disclosures, procedures, training, marketing, servicing, reporting, accounting, compliance review, testing, technology changes, vendor work, and ongoing product management.
There may also be new operational exceptions, fraud considerations, customer-service questions, and reconciliation requirements.
Then the product has to remain in the portfolio.
Someone has to monitor performance, maintain documentation, manage changes, respond to issues, and eventually decide whether the product still belongs there.
A product that is easy to launch can be expensive to own.
That doesn’t mean don’t build it.
It means include the whole lifecycle in the decision.
Don't let the competitor make the decision for you
Competitive analysis matters.
If customers can get something important elsewhere that you cannot provide, you need to understand it.
But “Competitor X has one” is not a product strategy.
Competitors have different customers, economics, technology, risk appetites, distribution models, and strategic objectives.
A feature or product that makes perfect sense for them may make very little sense for you.
Use competitors to understand the market.
Don’t outsource your roadmap to them.
The better question is whether the market has revealed a customer need that your existing product set does not adequately address.
Improvement usually wins when the underlying proposition still works
Improving the existing product generally makes more sense when the fundamental customer need hasn’t changed.
Maybe the pricing needs adjustment.
Maybe a feature needs to be added.
Maybe an unnecessary requirement can be removed.
Maybe the onboarding process needs to be simplified.
Maybe the product needs to be repositioned for the customers who actually value it.
Those changes can produce a materially different customer outcome without creating another product for the organization to support.
Improvement is not automatically the conservative choice.
Sometimes it is the faster and more economically rational form of innovation.
A new product makes sense when the difference is real
There are times when modifying the existing product isn’t enough.
A new customer segment may have materially different needs.
The economics may require a different pricing structure.
The servicing model may be fundamentally different.
The risk profile may require different controls.
The value proposition may be distinct enough that trying to force it into the existing product creates confusion for customers, employees, or both.
That’s when a new product can create useful separation.
The test is not whether you can create another product code.
It’s whether the difference is meaningful enough to justify one.
Consider what happens to the old product
One question is routinely forgotten during product development:
What happens to what you already have?
If the new product serves essentially the same need, will existing customers migrate?
- Will both products remain available?
- Will one become a legacy product?
- How will employees explain the difference?
- Will pricing differences create customer complaints?
- Will operations now support two processes instead of one?
Adding a product without making a portfolio decision can create complexity that lasts for years.
Sometimes the best product-development decision includes retiring something else.
Test the smallest change that can answer the question
Not every idea needs a full launch to determine whether it works.
If the hypothesis is that pricing is suppressing acquisition, test pricing where appropriate.
If customers are abandoning the application, address the friction before redesigning the product.
If a feature is supposed to increase engagement, determine whether it can be introduced to part of the existing portfolio and measured.
If you’re uncertain whether a segment values the proposition, find a way to test that assumption before committing to the full build.
The objective isn’t to avoid making large decisions.
It’s to learn enough that the large decision is based on evidence rather than enthusiasm.
Build new when new is the answer
There is nothing wrong with building a new product.
The mistake is assuming that “new” is itself the strategy.
Start with the problem. Understand how the existing product is performing. Determine what can be improved, what the customer actually needs, and what the economics support.
Then decide whether the smallest effective solution is an enhancement, a repositioning, a process change, or a genuinely new product.
A Product & Payments Strategy engagement can help evaluate the opportunity, diagnose the existing product, define the requirements, and determine which path creates the strongest customer and business outcome.
The goal isn’t to build more products.
It’s to build the right ones.