How should Product and Engineering shape a Feature together?

Feature shaping is the work between identifying an opportunity and committing a team to deliver a particular response. Done well, it combines product context with engineering judgement while there is still room to change direction.

Shaping is not Product writing a detailed Feature and asking Engineering to approve it. Nor is it an open-ended workshop in which every decision belongs to everyone. It is a focused collaboration that creates enough clarity for a responsible decision while preserving the accountabilities of each role.

Begin with a decision-ready problem frame

Product should arrive with a concise account of who is affected, what they are trying to achieve, the evidence for the problem, the desired outcome and why it matters now. Relevant policy, commercial, operational or timing constraints should be visible. Product should also distinguish genuine constraints from preferences inherited from an earlier solution idea.

This frame gives Engineering something meaningful to interrogate. Engineers can identify system behaviour, dependencies, data limitations, security concerns and opportunities that may not be visible from the customer journey alone. Design, research, operations or other specialists should join when their knowledge is material to the decision.

The team does not need certainty before it starts. It does need a clear question. “How might customers amend a payment date without creating unaffordable arrears?” is shapeable. “Build an edit-date screen” has already closed much of the useful option space.

Explore options against the important risks

The group should generate and compare more than one plausible response, including a smaller change or a non-software intervention where appropriate. Product tests whether an option could create meaningful value. Design examines usability. Engineering tests feasibility and technical consequences. The wider organisation may need to test legal, commercial or operational viability.

These perspectives are complementary, not a sequence of approvals. An option that is technically simple but does not change the customer outcome is weak. So is an attractive experience that depends on unavailable data or unacceptable operational work.

Evidence should match the uncertainty. A short technical investigation may resolve an integration question; a prototype may test whether users understand a choice; analysis may show how frequently the problem occurs. Shaping should reduce the most decision-relevant uncertainty, not attempt to eliminate all uncertainty.

Define a coherent boundary and a learning plan

A shaped Feature needs an explicit outcome, scope boundary, important scenarios, constraints, dependencies and acceptance signals. It should state what is deliberately excluded. Engineering can then explain likely approaches, size, confidence and the factors that could change the estimate. Product can decide whether the expected value justifies that cost and risk.

The smallest useful Feature is not necessarily the smallest technical task. It is a coherent change that can deliver or test something meaningful. Slicing should preserve the ability to observe a user or business effect, while avoiding unnecessary completeness.

Agree how the team will learn after release. The measure might combine customer behaviour, service performance, operational impact and technical health. If the change is primarily an experiment, state the decision the evidence will inform. This prevents “released” from being mistaken for “successful”.

Finish with clear ownership and a durable record

Shaping should end with an explicit decision: proceed, investigate, reshape, defer or stop. Product owns the value and priority decision. Engineering owns technical integrity and the estimate. Where risks cross those boundaries, the agreed governance or escalation route applies.

Record the problem, outcome, chosen boundary, important assumptions, rejected options, dependencies and unresolved questions. The artefact should be concise enough to maintain and rich enough that people who were absent can understand the reasoning. It supports continuing conversation; it is not a contractual hand-off.

Shaping is also revisited. Delivery may reveal new information, and results may invalidate an assumption. Product and Engineering should adjust together rather than defend the original document. AI can help organise evidence, expose missing questions or summarise decisions, but its output must be checked against customer evidence, technical reality and accountable judgement.

Example

A retailer wants customers to receive delivery updates because “Where is my order?” contacts are rising. Product brings contact data, customer research and the desired reduction in avoidable enquiries. Engineering explains that real-time courier events are inconsistent across partners, while reliable milestone data already exists.

The group compares a live tracking map, milestone notifications and improved self-service status. They select milestone notifications for the highest-volume journeys, exclude two unreliable carriers, and agree to measure message delivery, self-service use, contact demand and opt-outs. Product owns the priority and outcome; Engineering owns the integration design and sizing. The rationale and exclusions are captured for delivery and later review.

FAQs

• How long should Feature shaping take?

  It should be proportionate to value, uncertainty and reversibility. A familiar, low-risk change may need one short conversation; a costly or regulated change may require research, technical investigation and several decisions. Set a decision point rather than allowing shaping to continue without purpose.

• Who should attend a Feature-shaping session?

  Include Product and Engineering, plus the people needed to test the material risks. That may include design, research, data, security, operations, commercial or policy specialists. A large standing meeting is not required when focused contributions can be obtained another way.

• Is a shaped Feature ready for delivery?

  It is ready for the next agreed decision when its outcome, boundary, important risks and unknowns are understood well enough. Teams may still refine implementation detail during delivery; shaping should not become an attempt to specify everything in advance.