If you are working in a problem space that is new to you (or perhaps even to the world), attempting to come up with detailed plans up front is likely to be a huge waste of time.
But does that mean that in the early stages of a project in unknown terrain, you throw spaghetti at the wall and see what sticks? Not quite.
Instead, this is what you can do: Work in very small chunks, relative to the resources and time you have available. In the context of a solo developer working on a side project, this might be a couple hours of time per experiment; for a company with sufficient budget… it may be a couple weeks of development time.
Don’t stop at one experiment, though. Build a small portfolio that aims at different angles of the problem space you’re exploring. Limit the size of that portfolio based on the time you have available; there’s no point in putting ten experiments out in the world if you only have enough bandwidth to support feedback on three of them.
From there, share the work and try to see what captures the interest of the audience you’re trying to reach. But don’t push too hard, especially if you don’t know the people in that space yet. Spend most of your time listening, tune your experiments based on what you’ve learned from observing the people in that space, and don’t be afraid to abandon the experiments that you know you got wrong, or that didn’t bear fruit.
Over time, a combination of luck and learning, along with a whole lot of hard work and patience WILL generate some sort of spark. Once something starts getting traction, then do more experiments in that area… until you start to see the faint pencil sketches that outline the space you’re in.
Once you get there, then it’s time to gradually shift into a different way of working. Now attention shifts from drawing the outer lines of the figure to filling in the details.
A steady and growing stream of people using your software, responding to your writing, whatever… is a sign that you’re starting to produce disproportionate value. Revenue is the strongest indicator of value, but sharing, repeated visits, etc… all of these tell you that you’ve built something worth fine-tuning.
When you reach that stage, it’s time to start partitioning the space: Maybe you still reserve some of your time for free-form experimentation, but that becomes 20-30% of your effort. 70% of your time shifts to operating and tuning the engine that you managed to create.
At this point, yes, careful planning starts to matter… mostly because you actually have the feedback loops to support it! Wild guesses tighten up and become testable hypotheses — return on investment is actually considered before work is done, etc.
The simple starting point for tightening up focus is probably to start with AARRR metrics on the product side (Acquisition, Activation, Retention, Revenue, and Referral) — and throughput metrics on the development side (average cycle time for delivery, average # of WIP tasks, minimum response time, etc.). From there, you need to specialize for the industry you’re in.
The challenge we have in the software industry is that for both product designers and software developers, the folks who are good at the exploratory stages of a project are not usually the same folks who are good at the “measure twice, cut once” way of thinking. And yet any successful project will go through both of these phases, so some sort of attention ought to be paid to the crossover point.
I don’t have a direct solution to that problem, but it’s definitely something to think on for business people, product designers, and developers alike. This is a submarine in the waters that has sunk more projects than any of us would care to admit.
PS: It’s worth noting that none of these thoughts are original. They’re all found in Agile, Lean, and various other modern product development methodologies. For my part, I’d say that those who want to dig deep ought to read Reinertsen — because he takes an economics focused view of the problem and that leads to some unique perspectives.