For whatever reason, this tweet got me thinking about an exercise I periodically like to do related to developing your own product-sense.

It’s an inversion exercise - akin to the PRFAQ strategy at Amazon1 or “pre-mortems”2.

I call it the “Jeopardy Exercise”.

Whatever artifact3 you have in front of you is the answer to some unknown question. This thing was built in response to someone asking a question and forming an answer to that question.

The Jeopardy exercise is to try to do the opposite. You already have the answer (in the artifact). Now you need to try to derive the question.

This thing was built in response to someone asking a question and forming an answer to that question. The Jeopardy exercise is to try to do the opposite.

In the case of this particular quote tweet, there is a banking software service (Mercury) where a user is able to set up a recurring wire payment in 52 seconds. Now I personally have no need for this type of service. But judging by @Patio11’s commentary and his payments industry clout, this must be a simply delightful capability for a banking service to have. And 52 seconds appears blazing fast compared to most of other banking providers.

That is the answer you possess: 52-second-recurring-wire-setup.

What is the question?

A few questions might be:

  • “How do we design wires so they don’t suck?”
  • or “How do we make wires 100x easier than they are today?”
  • or “How do we get someone able to set up a recurring wire in 52 seconds?”

All of these are great questions to answer if you are running a banking SaaS! And for product-sense in general, it’s mostly good to have low variance in “Jeopardy exercise” question-answers. You want your users to infer you are operating in response to questions that all bear semantic similarity to “How can we build the best|fastest|highest-quality|most-reliable Z experience possible?”4

These questions are also good, because if you had prompted an engineering team with those questions, they would mostly be able to answer it with something mostly good (execution does matter, but these questions we prompt ourself with matter even more so! Context engineering FTW)

The thing this Jeopardy exercise, and other inversion thinking exercises, are really good at surfacing are the instances where you are building something in answer to sucky or ill-defined questions. Bad questions. Useless questions. Questions that nobody actually cares how you answer them. Or if you even answer them at all.

So next time you create an artifact, run this Jeopardy Exercise in your inner-loop5.

If someone can look at your road-map/sprint-plan/product-spec/pull-request artifact, and plausibly propose (Jeopardy-style) that this artifact was the answer to the question “How do we occupy X engineering weeks?” or “How do we fill the sprint” or “How do we give <XYZ> person something to do?” or “How do we complete this ticket with minimum effort?”. It is time to go back to the drawing board.

Ask yourself more ambitious questions -> Solve more ambitious problems.

  1. PRFAQ (Press-Release and Frequently Asked Questions) is an Amazon strategy for product development. You start the beginning of a project at the end. You assume that you are at the end of the project, after you have finished developing everything. The only thing left to do is to draft a document that contains a press-release for the project along with a FAQ document for users answering common questions.

    By starting at the end, you try to answer all the big questions up front. Including questions about what your product explicitly does/does not do. ↩︎

  2. “Pre-mortems” are also a product development exercise. You conduct a “post-mortem” (traditionally done AFTER a severe incident or service failure) in arrears.

    Gathering everyone in a room before the project begins, you lead with some form of the hypothetical question: “Even though we did everything we thought was right for this project, it still failed horribly. What went wrong?”

    This is a good mechanism for surfacing dissent and uncovering potential risk BEFORE it becomes disastrous. ↩︎

  3. Artifact is generic term for a tangible thing you can observe. Could be a product feature. Could be a napkin sketch. Could be a RFC document. Could be a pull-request. Could be a branded campaign plan. Etc. ↩︎

  4. You can also incept these questions into your users vocabulary with strong brand-marketing. Elevate concerns like “speed”/“quality”/“reliablity” into their conscious awareness. Then back it up with WOW moments and watch the NPS scores soar. ↩︎

  5. Running an exercise in your inner-loop is also known as “talking to yourself” - however you structure that conversation. I get a lot of benefit from writing things down in a structured way. But YMMV. ↩︎