Make It Possible, Then Make It Easy

Note: While I work at AWS, the perspectives shared in this article reflect my own personal views.

One thing I’ve consistently seen leading development teams: no matter how small the feature, people want to build it perfectly — at least at the outset, before deadlines loom and resources stretch thin. You might think that’s a good thing, right? Everyone aiming to deliver outstanding features for customers sounds ideal.

But here’s my contrarian view: it’s not — at least not at first.

The core issue is this: product and engineering teams often have a notion of what’s needed, but not an understanding. Why? Because customers ultimately define what they need, while teams define what they think customers need.

We’ve all been there — a product manager walks in with a meticulously crafted BRD, weeks of thought poured into every detail. Yet, how often does that BRD deliver exactly as intended, with universal customer praise? Almost never. And how often do big-bang features either flop or quietly get sunsetted? More often than we care to admit.

I call this assumption-driven development — building on what we think customers want, instead of what we know they need. And you know what they say about assumptions: they make an “ass” out of… well, you know the rest (I tweaked the old quip so I’m not the ass here — though perhaps that makes me one, which the kids today would call “meta” before Zuck rebranded it).

To be clear, this isn’t a knock on product managers; engineering leaders fall into the same trap. The outcomes are familiar:

    The feature ships, but no one uses it.
    The feature sees brief use, then drops off.
    Customers complain because it doesn’t solve their problem.
      

The underlying problem? Good intentions, poor outcomes.
A Better Approach

Different customers have different needs, and no amount of upfront research closes the inherent gap between what’s communicated and what’s understood. Remember the game of Telephone?

Instead of assuming, I coach my teams to apply a simple mantra:

First, make it possible. Then, make it easy.

In practice, that means focusing first on unblocking customers — even if the experience is rough. Don’t confuse this with shipping junk; it’s about unlocking value quickly, getting real-world feedback, and iterating fast. It’s lean startup thinking applied to enterprise engineering.
A Real Example

One of my teams runs Data Lake ingestion pipelines, including an ETL flow for SAP. Out of the box, we supported ~80% of the standard SAP tables, but custom “Z-tables” required extra work. The product and engineering teams wanted to build a polished UX for adding these custom tables — a classic BRD moment.

Instead, we followed make it possible: we exposed the connector configuration as a JSON file in the UI. Was it elegant? No. Did it work? Absolutely.

And here’s the magic:

    The JSON approach unlocked not just Z-tables but additional advanced use cases (like timing tweaks and row-level filters).
    We delivered value in weeks, not months.
    Customers started using it right away — and then asked for a better UX.
      

That’s the problem you want to have: customers using your feature so much they demand improvements. Now you can iterate, refine, and “make it easy” — and you do it with confidence that you’re solving a real need.
Why It Matters

If you hear crickets after shipping the MVP, great — you’ve learned cheaply that this isn’t a priority. If you’d gone big-bang from the start, you’d waste months and tie up resources that could’ve gone toward features customers actually care about.

So resist assumption-driven development. Focus on enabling outcomes first, and only then smooth the experience.

The road to hell may be paved with good intentions, but the path to great products starts with making it possible — then making it easy.