Startups: How to set a realistic timeline when building a software product

Will Little

“Sure, we'll have that done in three weeks.” says the engineer. The marketer rolls her eyes, of course, and expects it in five. Eleven weeks later, it's delivered (and it's not very good). After an additional seven weeks of ironing out the basic bugs and UX kinks, marketing finally feels comfortable promoting it. Why didn't the engineer just say “about 20 weeks” and aim for delivering a tad early?

If you've been in or around any part of this story, you know it well. As an engineer and product manager in startup land, I always think building a product will take less time than it actually does.

I somehow forget that time I wasted ten hours scouring API documentation and Google searches because I spelled “prototype” incorrectly as “pototype” — and of course the error message pointed me in a misleading direction (arg!). Or I'm happy to never recall the moment I realized there's a bug in the plugin we decided to use, after spending 5 hours thinking it was my fault for not reading the documentation right.

These things take time.

BUT, especially as I roll further into my second decade doing this work, occasionally the stars align, things go smoothly, and my team is ready many weeks in advance.

How, then, do we communicate and plan effectively?

Agility

If you're not familiar with Agile Software Development, you should be (take a few minutes to scan the wikipedia article).

Every software team I've worked with has their own flavor of how exactly to roll with Agile, but the principles are essentially the same:

1. Customer satisfaction by early and continuous delivery of valuable software

2. Welcome changing requirements, even in late development

3. Working software is delivered frequently (weeks rather than months)

4. Close, daily cooperation between business people and developers

5. Projects are built around motivated individuals, who should be trusted

6. Face-to-face conversation is the best form of communication (co-location)

7. Working software is the principal measure of progress

8. Sustainable development, able to maintain a constant pace

9. Continuous attention to technical excellence and good design

10. Simplicity — the art of maximizing the amount of work not done — is essential

11. Best architectures, requirements, and designs emerge from self-organizing teams

12. Regularly, the team reflects on how to become more effective, and adjusts accordingly

Practically, when things are going smoothly, product specifications (specs) are translated nicely into epics and user stories, and prioritized smartly into sprints. We'll talk more about this as it relates specifically to visual design and engineering in future articles, but for now you should think about sprints in terms of what it takes to actually launch your business.

At any time, marketing/sales (or any stakeholder) can peer in and see how things are going.

For Startups

So ok — sure — there has been plenty of content written on Agile methodologies, but how does this help you as a founder communicate with your team and advisors (even if it's just a couple people)?

If you've been following along with my pre-launch operations series thus far, we've already covered the process from ideation to conducting smart validation experiments. Assuming you have sufficient data telling you it's a good idea to proceed, now it's time to lock down your game plan and get everyone on the same page.

Using a Shared Document, Gantt Chart, and Project Management Tool

I know this sounds obvious, but you'd be surprised how many founder teams fail to put in writing the plan to tangibly build the product and launch it. According to the framework we are walking through in this series, you still have the following 18 steps left to tackle before launch:

1. Funnel Stages & KPIs
2. UI Spec
3. Tech Stack Decisions
4. Database Architecture
5. UX Flow Chart
6. Moodboard
7. Name
8. Logo
9. Financial stuff
10. Legal stuff
11. StyleTiles
12. Wireframes
13. Mockups
14. Prototype
15. Private Alpha
16. Coming Soon Page
17. Closed Beta
18. Open Beta

The easiest way to proceed from here is to write down these 18 steps in a document (we normally use a Google Doc) and, from top to bottom, put in how many days/weeks you think each will take (and who is responsible for running point on each).

Then, construct a very basic Gantt Chart, which is used to “illustrate the start and finish dates of …elements of a project.” A tutorial of how to create a (free) Gantt Chart in Google Sheets, for example, can be found here.

From there, translate this into your project management tool (I'd suggest Asana, in an operations project, which I'll write more about later), assign each task to the lead, and set a due date based on the time you estimated it will take (taking into account the other tasks on this person's plate).

Looking at these tools together will then give you a fairly realistic timeline of how long these 18 steps will take (and yes, if you've been honest with yourself and your team, this will probably be much longer than you anticipated).

Your timeline is wrong, but get to work anyway

Finally, make sure you and your team know that the timeline you just put together is wrong. It will mostly likely take much longer than everyone (including marketing) thinks, but it's possible the project may go quicker.

Either way, don't spend too much time refining these documents and tasks once you've set them up. Now that you have a basic plan in place it's time to get to work, run your sprints, and communicate regularly with your team as you go.

Author's note: this is the 11th post in a series of articles outlining a framework for pre-launch startup operations that my partners and I have developed over the past dozen years or so. (FYI: we're building a SaaS product to help founders work through the framework and get connected to co-founders + advisors/investors along the way — jump into the private beta queue here). Also, feel free to subscribe to my newsletter and I'll let you know when I get new content up. Thanks!