As I have gained more experience as a product designer, I think it has generally gotten easier for me to navigate the process of making products. That's not to say that all my ideas are good. Most of them are bad! But I do have a much easier time figuring out what to do next, whether that's canning the idea, doing more research, or building a prototype. I thought it might be useful to others to share my overall approach, and hopefully people can tell me how wrong I am and how I can do it better. I think there's also one rule the subverts any of these steps, which is that the main goal is to learn as much as possible as quickly as possible, so if any step feels like it's mostly a performance, don't do it!

Step One: Do user research to validate Jobs to be Done
Outcome: We all agree on what problem we’re making this to solve (e.g. When I'm looking for games to play with family and friends, I'm looking for something easy to set up and play, so I can have fun with my friends without giving up too much of my life)
Notes: It doesn't matter, from a product point of view, who is hiring for this problem. They could be from any demographic. I'm only going to take demographic information into account inasmuch as it allows me to make a more useful product. Bic for her is a tragic case of a product taking demographic information into account when it really shouldn't. The problem to solve is "a good pen for writing" not "a pen that is clearly for women".

Step Two: Ideate things we can build that solve those problems
Outcome: We have a few ideas for how we can solve these problems in an end-to-end experience. (e.g. Pre-made characters and campaigns, a new RPG with a ruleset that better suits this JTBD, a suite of digital tools that make existing RPGs much faster to run, an AI dungeon master that handles all the hard parts so you don't need to prep)
Notes: It's important at this stage to understand an end to end experience. Abstract ideas are hard to relate to and evaluate. Different people on your team will have a different idea of how it comes to life, and it will be hard to agree on what exactly this thing needs to do to solve the Job to be Done. Evaluating an end to end experience increases the chance that everyone is talking about the same thing.

Step Three: Place bets
Outcome: We decide which ideas are worth prototyping a proof of concept to show to users (e.g. AI dungeon master is too hard, but pre-made characters and campaigns are too crowded of a market, so let's focus on the new RPG)
Notes: The idea of placing bets comes from Sahil Lavingia. It builds in the idea of uncertainty and chance ahead of time, so that people can feel more comfortable handling failure, and committing resources to something with unclear results.

Step Four: Develop a proof of concept
Outcome: We have a functional end to end experience which users can use to solve their problem as articulated in step one. (e.g. paper prototype that we can playtest with users)
Notes: Predicted behavior is not as good as revealed behavior. Launch as real of a proof of concept as possible so that you know you are dealing with revealed behavior and not predicted behavior. A figma prototype is not as good as a staging link. If you feel like you’re not able to commit to developing the prototype, that probably means you either a) don't actually feel that confident about the JTBD from step one or b) don’t feel that confident about the bets you’re placing in step three. If you find yourself in this position, I recommend going back to step one and doing more research. You should feel like you’re doing users a favor when you email them this early staging link to try out and give feedback. If you feel like they’re doing you a favor to check it out and give feedback, go back to step one!

Step Five: Decide on what quantitative and qualitative data you care about for analyzing this proof of concept. Also decide on how much of that data you will need to feel good about making a decision to either continue investing in the idea or cut it out.
Outcome: You know what success and failure look like. (e.g. A majority of the users we share the prototype with use it. Games that get played take 5x or 10x less time to set up. At least 20% of the people who use it are able to make concrete progress on their JTBD from Step One with the prototype.)

Step Six: Launch the proof of concept to a limited audience and collect the data needed based on step five.
Outcome: You’re ready to make a decision on what to do with the proof of concept. (e.g. Let's produce a limited edition of X and bring them to market with a marketing budget of Y)

Step Seven: Decide whether to do additional iteration cycles, launch to everyone, or sunset the idea.
Outcome: You’re “done” this iteration cycle. Success is going to be determined by the speed and quality of these iteration cycles and the learning rate between them. If you’ve picked a market with a real need, and do a good job at these, you’ll eventually find product-market fit

P.S. I wrote most of this text for Ought, who is doing very inspiring work - go check them out!