| This is what I consider to be a "plan": > Problem definition
> Product solution
> Technical solution
> Task breakdown
> (optionally: > Estimation > Timeline) Of course there's always some feedback loop between items in the sequence but for given scope it's a good idea to minimize it. Or in other words:
Pick a scope/feature/project, let's say proof of concept for your initiative. It seems like your problem description is robust enough so let's skip to Product solution. It's a good investment to define everything you can define before stating actual implementation. If you still have some questions to answer then get the answers if that's possible. People have the tendency to leave the "unimportant" details for later but there's no gain in that. You have to spend the time sooner or later anyway. Better to do it sooner because sometimes the "unimportant" detail forces you to go back and rework bigger part of your solution. Have your entities defined, user stories, UX mock-ups ready before working on technical solution. Have a technical solution described and validated before you start implementation. This way you mitigate the risk of being forced to go back to previous steps wasting time or being stuck with sub-optimal solutions. So regarding the parent comment. If you know enough from the users/market research/cogitating to be reasonably sure about the next step then execute it. Once you get there it's time to continue the research with what you already have in mind. Otherwise you risk getting stuck in an endless loop of tweaking and changing decisions without reaching tangible milestones. |