Technical feasibility for Product Managers: the checklist I use before committing

A checklist for Product Managers to assess technical feasibility before committing: user behaviour, systems and data, integrations, failure cases, delivery, and unknowns.

Kinga Magyar · Published 7 September 2026

As a Product Manager, I've had to answer versions of the same questions many times:

"Can we do this?"

Usually followed quite quickly by, "And how long will it take?"

Sometimes the proposed change looked tiny. One new button, an extra field in a form, a setting someone wanted added. I could see the visible change, but I couldn't yet see which systems, data or teams it would affect.

To be honest, saying "I don't know yet" never felt particularly comfortable. But a commitment made before the team had examined the dependencies and unknowns could force us to revise the scope or timing later.

So I learned to slow down that first conversation and assess the technical feasibility of the change.

Technical feasibility is an assessment of whether a proposed change or feature can work within the product's systems, data, integrations, team skills and delivery constraints.

A Product Manager's role in that assessment is to make the proposed user behaviour clear, ask questions that expose dependencies and uncertainty, and record what we know before anyone promises scope or timing. Engineering owns the technical assessment and implementation approach.

Here is the checklist I use to structure that conversation.

My technical feasibility checklist

I start by making the feature specific. "Can we add subscriptions?" gives an engineer very little to assess. I would describe the behaviour more like this:

A workspace owner can pay for ten seats by card, add more seats later and receive one monthly invoice.

Now we have a user, actions, states and an outcome. The team can start tracing what those actions would touch.

1. Clarify the user behaviour and states

• Who can take the action?
• What must be true before they can take it?
• What changes after they complete it?
• Can they undo or repeat it?
• Which permissions, account states or edge cases change the behaviour?

I have found that states expose quite a lot of hidden work. "A customer can cancel" becomes several different behaviours once we ask whether the order has been paid, packed, dispatched or partly refunded.

2. Ask what happens to the systems and data

• What will change on the frontend, backend service, database or internal tool?
• Where does the source data come from?
• Which system becomes the source of truth after the change?
• Does existing data need to be cleaned, moved or recalculated?
• Does the change involve personal, payment or other sensitive data?

I am trying to follow the user action through the product here. If a customer changes something on screen, which system records it, which other systems need the new value, and what happens if one of them keeps the old value?

3. Look for integrations and dependencies

• Which other teams, services, APIs or vendors does this depend on?
• Do those systems support the behaviour we want?
• Are there rate limits, contract limits, approval steps or release dates?
• What happens if an external service is slow, unavailable or returns an error?

Dependencies are often where a confident "yes" turns into "yes, if". It's important to write down the condition after that "if", because it can change the scope, timing or decision.

4. Ask how it could fail

• How could the feature fail for a user?
• Which failure cases must the team test before release?
• What will support teams need to see when something goes wrong?
• How will the team detect incorrect data or behaviour?
• Which accessibility, security, privacy or regulatory checks apply?

I can sound a little pessimistic when I ask these questions. I quite like this part, though. It gives the team a chance to design the failure behaviour while the feature is still being discussed, rather than after a customer has found it for us.

5. Ask how we could deliver and release it

• Can we divide the work into a smaller useful version and later additions?
• Do we need a technical investigation, prototype or proof of concept before estimating the feature?
• Can we release it to a small group first?
• How will we monitor the release?
• What do we want to measure once the feature is live?
• Can we disable or roll back the change safely?

When a feature is difficult to estimate, the next useful step may be a short technical investigation. That gives us a way to answer a specific unknown before asking for a delivery estimate.

6. Separate facts, assumptions and unknowns

• Which answer is supported by evidence?
• Which answer is still an assumption?
• What could make the work materially larger?
• Which decision would be expensive or difficult to reverse?
• What is the cheapest safe way to answer the biggest unknown?
• Who owns that next step, and when will we know enough to decide?

The first meeting can end with unanswered questions. Just make sure that each important unknown has an owner and a next step, so it doesn't disappear into the meeting notes.

A fictional example: changing a delivery address after checkout

I'm using a fictional example here because I don't want to turn a real company's systems into a neat little story that never happened.

Imagine this request:

Add an edit button so a customer can change their delivery address after placing an order.

It looks like one button and one form on screen. So what would I ask before making a commitment?

A screen count tells me very little about scope. This conversation helps the whole team trace the proposed action through data, integrations, states and failure cases.

How to discuss rough scope without pretending we know more than we do

So, can this conversation give us a rough scope? Yes, once we are clear about the uncertainty that still sits behind it.

I ask the engineers for two things:

1. A relative complexity judgement, such as low, medium, high or unknown.
2. The reasons that judgement could change.

For the delivery-address example, the answer might be:

Medium if the courier API accepts updates before fulfilment and the order service already records address history. High if we need cancellation and replacement across several fulfilment partners. We need to check two APIs before estimating.

I can work with that answer. It tells me what the current judgement depends on, which evidence is missing and what we need to investigate next. An unsupported number of days would give me none of those things.

The technical feasibility summary you can take away

After the conversation, I write down the decision, evidence and open questions in one place. You can copy this version:

# Technical feasibility summary

## Product decision
[What decision are we trying to make?]

## Proposed user behaviour
[Who does what, under which conditions, and what changes afterwards?]

## Affected systems and data
- [System, service, database or internal tool]
- [Data read, created or changed]
- [Source of truth]

## Integrations and dependencies
- [Team, API, vendor, approval or release dependency]

## Important failure cases
- [Failure case and user consequence]

## Delivery and release considerations
- [Testing, rollout, monitoring, analytics and rollback requirement]

## Known facts
- [Evidence-backed fact]

## Assumptions and unknowns
- [Assumption or unanswered question] – Owner: [name]

## Rough complexity
[Low / medium / high / unknown]

This judgement depends on:
- [Condition that could change the size or approach]

## Recommended next step
[Decision, technical investigation, prototype, data check or narrower scope]

What I own as the Product Manager

The Product Manager owns the decision context:

• the user problem and intended behaviour;
• the evidence that makes the work worth considering;
• the constraints and product trade-offs;
• the assumptions we need to test;
• the record of what we know, what remains uncertain and what we recommend.

Engineering owns the technical assessment and implementation approach. We work together to understand the product behaviour, affected systems, risks and missing evidence.

Over the years, I have become more comfortable saying that I need another answer before I can commit. I feel confident when I know which questions to ask, can recognise an assumption and wait for the right evidence before promising scope or timing to a stakeholder.

Become a Technical Product Manager Without Becoming an Engineer

We're testing interest in an upcoming Little Parrot transformational learning path called Become a Technical Product Manager Without Becoming an Engineer.

It's for non-technical software Product Managers who want to understand how their product works, investigate questions and contribute to scope and trade-off decisions with clearer evidence. The learning path isn't available yet. If you'd like us to tell you when it opens, visit the landing page and register your interest.

If you want to try the checklist first, take one roadmap item currently described as "small" and write down the user states, systems, data, dependencies and failure cases it could involve. Which questions do you need an engineer to help you answer?