Skip to content

Do We Have This Feature?

TL;DR

Your customers don't know what they want. Build 80% solutions and adapt when reality hits.

We've already talked about ETAs in What's the ETA?. Another classical question for product and engineering teams is:

  • "Is this feature available?"

  • "Do we already have XYZ?"

  • "How much is built vs. how much is aspirational?"

They're valid questions.

Sometimes the answer is crisp and simple:

  • If it's deployed, so the answer is a "yes, we have it!"

  • If there's nothing in the codebase, the answer is a clear "no, we don't have it".

For the other 99% of cases, the honest answer is: "it depends." The goal isn't to dodge the question; it's to explain what exists today, what's missing, and how quickly we can responsibly close the gap.

Here is where customers/management might play the card "I just need a yes or a no". This is a tricky situation that we will address in a future post. For now, let's assume the conversation is calm and collaborative, stakeholders are genuinely curious and focused on understanding the trade-offs, not on picking a fight.

Research Vs. Engineering#

Not all software work is created equal. Classifying the work first makes conversations faster and clearer.

1) Research Problems#

These are open-ended efforts where the solution is not yet clear, but iteration and discovery are necessary.

  • Example: building and validating a new machine learning model

In this case:

  • Try–learn–adjust until it works (or time runs out)

  • Progress is not linear

  • "One-size-fits-all" plans rarely apply

  • Estimates are ranges with large confidence intervals, not points

This is a complex topic that will address in a future post.

2) Engineering Problems (Solution Understood)#

We generally know what to build; the challenge is doing it well, on time, and on budget.

Risks to manage include:

  • Expectation-setting

  • Scope creep ("featuritis")

  • Late-second changes

  • Occasional unknown unknown

"It's Done" Is Rarely Accurate#

Even for engineering work with clear specs, "done" is a moving target. Customers often describe outcomes loosely. Things I've actually heard from customers:

  • "How do I build what I need to build?"

  • "Why don't you build what you think I want?"

  • "It's simpler to build than explain—ship something and I'll tell you if it's right."

As you can see, you can't win in this situation and the only solution is not to play until the goal post is clear enough.

In these cases, I aim for "80% complete and adaptable." Architect the software for change so last-minute customer insights can be incorporated quickly when they're valuable. Startups live in shifting contexts, flexibility is a feature.

Do We Have This Feature

A Straightforward Communication Framework#

When asked, "Do we have this feature?" respond with:

  1. Status today: Do we have something close to the feature?

  2. Type of work: Research vs. Engineering (or a blend)

  3. Effort estimate: Person-hours with uncertainty bands (as in What's the ETA?)

My approach is to estimate effort (with the same caveats from What's the ETA?) and then let product/GTM decide how fast it should go based on economics. We then right-size the team to hit that date.

To ensure that the deadline is predictable and hit, I obsess on

  • Teams that are aligned on the process: they have common code style, reviews, and release routines

  • Code that is documented, well tested : shared patterns, shared context

  • Architecture that is modular and clean so adding people adds throughput, not entropy

Then scaling up or down is much easier to achieve things on time and on budget.

An exception is when there's a credible path to deliver within a few days with high confidence, I'll often answer "Yes, we have it", because the cost of signaling uncertainty can exceed the small inaccuracy of that phrasing—especially when the implementation is routine and low-risk.