Structuring your project
Usually, when I enter a consulting project, I see a mess.
Never I seen this due to malice, just usual negligence due to overload. And, of course, I've done same mistakes and suffered the outcomes.
It starts small. Just a little not-so-clear area in the project idea. "I'll think about this tomorrow".
Then, project grows, complexity increases exponentially and "tomorrow" never comes. There are many more urgent issues to solve: hiring, server provisioning, fundraising, compliance, etc, etc.
When the entrepreneur adds yet another person to the team, those "not-so-clear areas" grow to swamps of misunderstanding. Misunderstanding leads to wrong decisions. Wrong decisions waste resources. And, most importantly, they waste emotional energy and time.
Finally, the project dies due to resource misallocation, arguments between team members, general apathy, and, of course, lack of followup funding.
For the 25+ years of managing projects, I've found the following structure to be useful to think about the project. And the best way to capture current state of mind, is to document it.
Don't try to create a comprehensive document on the first run. Don't aim it at the second run too. Better focus on keeping them in a coherent state and update them as you learn. Start with just a placeholder in your project wiki and update as you go.
So, the structure:
Elevator Pitch (1 paragraph, 3-4 sentences)
Execute Summary (1 page)
Whitepaper:
Problem
Stakeholders and value for every one of them
Usecases
Tech solution
Project-specific parts (e.g. cryptocurrency projects usually have token economics here)
Investment proposal
Technical requirements
Users
Detailed usecases
Data structures
Screens
Work cards (also known as issues, tickets) and prioritized backlog, structured into sprints
DevOps (what's hosted where, who has access, what's logged, what are failure modes)
UI/Branding guide
If your project is in an active fundraising mode, add to the list
a teaser deck
complete deck for a qualified investor
detailed deck and supplementary for due diligence team.
Keeping that stack of documents in a coherent state allows every team member to understand how his personal task fits the whole picture. Your meetings would result not in a "wannado-till-next-week", but into a specific parts of the documents to be updated, development tickets resolved, servers and services configured, presentations prepared and delivered.
This means features delivered correctly, milestones achieved on time, faster iteration and learning, and, finally, a project success.
If you like what you’ve read, consider subscribing to my posts and commenting on twitter.