Had a fun conversation with a friend this morning, and it was sort of weirdly illuminating for me. My #productdevelopment process basically breaks down into two pretty simple concepts that are *incredibly* difficult to actually execute:

1.) Know what you’re trying to do. That is, you have to be super specific and use very precise language to articulate the one big idea that you’re building your product around. Every entrepreneur can describe their product *generally*, but I find very, very few who can do it with exacting precision. Who is your market? What problem is this solving? What is the benefit to the user? If you can do this in one crisp sentence, you’re way, way ahead of the game. But the funny thing? It’s actually less about knowing what you’re doing – most people can understand that. It’s almost entirely so you can understand what you are *not* doing, which is a boundary that a lot of entrepreneurs actually never quite figure out. Which leads to scope creep, bloat, and eventual death.

2.) In traditional product development, you might do some testing, but basically, you’re going to bundle up a bunch of stuff, release it at some point, and then either succeed or fail. For me, the goal of everything I do is “How do I disassemble that one giant ball of risk, and try to mitigate every individual piece of it as early and cheaply as possible?”

That’s it. If you want to reverse engineer almost anything I’d say about product development, it’s “Do you understand what you are trying to do, and how to make good decisions about whether or not to do something?” and “How do I make this less risky and learn earlier?”

Now, while they’re simple concepts, doing them in effective, meaningful ways is an incredibly complicated, nuanced, and product/context-specific challenge that’s new and difficult and surprising every single time.