How long do you spend in the "planning" phase?
Hello, long time lurker (first post!)
I want to get a feel for what kind of things you guys need in place before being comfortable executing on an idea?? If someone has a mental model or process they can share, I'd love to hear about it.
I consume a lot of information and re-plan a million times. I think I might enjoy the "rush" of planning more than executing. Does anyone else feel this way?
For me, initial planning usually takes around 4 weeks, which for some people may seem like a lot but it is worth it, especially if you're building your idea with the help of a team. The key goal is to eliminate uncertainty BEFORE your start building your product, so when you start designing and coding you know WHAT to build and HOW.
You have to be pragmatic though, because unorganized planning can lead to paralysis by analysis. The only way you can find the sweet spot is by experience, but I can describe you the process I use for reference. If you already have an idea of what to build, you can start doing these steps (in order):
start doing some user story mapping, this helps because you end up realizing that your project is bigger and more complex than you initially thought
then work in the user flows, based on the user stories you just made and make sure every single one is considered. you should iterate a lot in this step until you feel you nailed it
now go back to your user stories, because you probably found a way to make things easier or something else that affects the original user stories
once everything makes sense, describe the acceptance criteria for each user story, which should consist of 4 or 5 bullets
now start modelling your data... don't finish until you know how every user story affects your database. Seriously, don't skip this step.
now design your APIs based on your models and the user stories... by APIs I mean endpoints, methods or functions, whatever fits your coding style. The key points is that you think in terms of input parameters, output parameters and how those APIs affect your data.
when you have defined your APIs it is very easy to write tests, it depends on you if you want to write them before or after you code but seriously do it to prevent/detect regressions
start designing your screens based on the user flows and the user stories. here is where you make it look pretty and focus on user experience
now you just need to code it, setup a trello board using the kanban system and make sure your WIP doesn't exceed two user stories at the same time
It may sound like a very robust process, but it works wonders once you understand the value you lose by NOT doing it.
Hope that helps.
Hey luisehk, thanks for sharing the advice. How do you go about making user stories when you have no users (or do you do user stories if you have no users, even)? Do you do surveys then using that data make a model of an average user? If you have no customers, do you just try to hypothesize possible users? Thanks for reading this!
" unorganized planning can lead to paralysis by analysis." this is so true. I think I am guilty of this. Any words of advice @luisehk on this thing?
Key advice would be:
establish realistic deadlines and hold yourself accountable. track your progress using checklists or whatever works best for you
understand it is better to have something imperfect than nothing at all. don't let perfection stop you
don't multitask. start what you finish before doing something else
Thanks for this. Feels familiar... similar to my current approach. What type of cadence do you typically follow? I feel exhausted just looking at this list lol. Any way to make it more light-weight or iterative?
Sure thing. The process I describe is what has helped me to create good and maintainable products with little technical debt, when the product is already validated using design sprints and customer discovery.
I'm more of the opinion that you should validate the market by talking to your clients instead of releasing a sloppy product and then finding out, but there are very successful people who've done the opposite.
It depends on what method you prefer, they both have their pros and cons.
This is great, well thought out. Easy to tell you're speaking from experience. Would encourage you to blog about or document your process, if you haven't already!
I don't think there is a one-size-fits-all answer to this.
The only planning you need is talking with your potential users. Talk to them and try to disprove your hypotheses about the problem(s) you're trying to solve for them. Try very hard not to be biased towards a solution, put your brilliant idea aside, and try to find out if they really have the problem that you think they have. Don't ask hypothetical, "would you...?" questions, and instead focus on their past and current experience.
Take as much time as needed to speak with people and iterate on your hypotheses.
Once you've failed to disprove your hypotheses, start building, but not the final solution. Build an experiment instead. For example, if you've Identified a problem that people struggle to find good gifts for children, don't build an entire gift recommendation system. Instead, you might make a website with a contact form, promising that for a small fee you'll find them a gift that fits their budget and preferences. You'll have to manually help them out, and it won't scale, but:
it'll be super fast to ship
it verifies if there's a market for your idea
you'll learn a ton about the customers and their real struggles when it comes to buying gifts
you can gradually automate valuable and time consuming tasks and build out a more scalable solution.
I like this approach, makes perfect sense and forces me to validate assumptions. Thanks!
This is an equally valid approach especially for non-technical people. The Mom Test by Rob Fitzpatrick is a great concise guide for building products via this approach.
This comment was deleted 16 days ago.
Fundamentally, I think the most important thing to do is to validate that the problem exists via unbiased market research (see The Mom Test). Coding is generally the last thing I do for greenfield projects.
Come up with 3 questions to kickstart conversations with prospective users. The first should objectively tell you whether or not the person even falls in your target audience. The second two should provide data about specific experiences that you can then analyze for solutions. All of the questions should be phrased like “when was the last time you...”, “how many times would you say that you...”, and “tell me about the last time you...”. Don’t pitch an idea, have a conversation.
When you get to building the thing, I’d say that @luisehk’s approach is the way to go. You should be able to save yourself months or years of time via the market research phase. Two weeks of research should be more than enough!
Thanks for this, great input.
I had an idea two weeks ago about a project. I did some sketches and showed it to a couple of friends. I then jumped into building the application which I'm currently working on.
I believe you should ship something fast! your users will shape your project based on their needs if there is a market fit. So don't waist too much time planning! Ship Fast.
Way too long lol. I end up planning my plans lol.
Yes! I feel your pain lol.
lol
Take your time with planning but don't just spent time on planning because execution of your plan or project may take longer and then something can go wrong. You can start planning with basic & start working as well & then procede in same manner.
you might want to check out the business model canvas.