8
5 Comments

How much planning is enough?

submitted this link on January 19, 2023
  1. 3

    I can see this from both sides. Luke is right when he says that you can plan as much as you want but there will still likely be errors, but then if you can mitigate some of those errors and it's less of a deal now vs. fixing it in the future then best to take your time. Well-written👍

  2. 2

    I like this highlighted quote in the article:

    If you are running a project, always ask your team how something can be delivered in half the time. You can’t bend time and space; things will take longer than predicted. But you can have achieve outcomes sooner than you think

    I think that is a really useful question to ask yourself and your team as you move forward and iterate. You really have no idea what to optimize until you have something working end-to-end.

    1. 1

      Something I noticed in a lot of my past projects is that people tend to think about delivery as something that happens at the end. That adds a lot of pressure to get to get things right from the start. If projects can think of "outcome delivery" and "end of project" to be different things, learning can be had so much earlier before all the polishing starts.

      Asking the "what can we do in half the time" can help to surface some of these.

      Example...

      We switched a REST API to GraphQL in a project. Previous attempt to move another endpoint (high traffic) had taken 1.5y! When we asked ourselves "what can we do in a few weeks?"... well the outcome we were after was to cut our web+native clients over to same GQL services. We can do that by wrapping existing API in GQL -> Migrating Clients -> slowly gutting the REST API behind the scenes. Project outcomes in about 4 months, project end took another half a year.

      Thx for the comment, I wrote the post.

  3. 2

    Wise words. I don't work with tech but I can see how this translates to planning in just about any industry. Sometimes you just have to move forward knowing things can still go wrong and other times taking your time to iron out potential issues is the best way to save time and money in the future. Food for thought indeed.

  4. 1

    Gives me lots of insight, thanks for sharing!

Trending on Indie Hackers
From building client websites to launching my own SaaS — and why I stopped trusting GA4! User Avatar 38 comments The “Open → Do → Close” rule changed how I build tools User Avatar 31 comments I lost €50K to non-paying clients... so I built an AI contract tool. Now at 300 users, 0 MRR. User Avatar 23 comments Everyone is Using AI for Vibe Coding, but What You Really Need is Vibe UX User Avatar 22 comments I built a tool that turns CSV exports into shareable dashboards User Avatar 20 comments Learning Rails at 48: Three Weeks from Product Owner to Solo Founder User Avatar 19 comments