Process, Resources, and Milestones
A simple way to create a cohesive process and identify needed resources and incremental milestones. - Part 10 in "Building a product saga"
TL;DR:
Knowing HOW you will build your product is as important as WHAT you want to build.
When organizing your product development, you need to define clearly:
Your project management process includes:
The cadence of interaction includes requirement review, priority adjustments, code/complete work demonstrations, and releases.
Communication methods and frequency
Resources that you need, including:
Expertise, software license, physical materials, office space/environments, etc.
Identify what key milestones your roadmap needs to mitigate or avoid risks associated with your roadmap.
Breaking it down further:
Project Management: Consider how frequently you will:
Able to adjust priority and share the update
Adding or adjusting requirements and sharing them with the team
Review finished work, including quality checks, acceptance testing, and other validation
Review and update your process
Have formal communications, such as daily stand-ups, weekly status meetings, retrospectives, requirements reviews, backlog reviews, and so on
Resources: Consider what you need to deliver your roadmap, such as:
What technology do you need to consider, test, and acquire
What expertise, knowledge, or community/network you need, either to do the work, or to operate your software, and so on
What physical equipment, space, and raw materials will you need, such as computers, machines, office space, desks, meeting rooms, factory space, warehouses, etc.
Key milestones: Are the interim deliverables, metrics, or activities that will help you anticipate issues in delivering your roadmap to help you pivot or track progress so you know when to step on the gas or if everything is on track.
Defining the process you will use to manage your projects, the resources to execute them, and key interim deliverables will improve the odds of turning your roadmap into reality and value for your customers.
The story so far
After pivoting my strategy and defining a new set of values and markets to focus on, I defined a roadmap that includes what will be in the MVP and subsequent improvements. (See here), now, I’m almost ready to start executing against it. But before I start writing codes, I need first to figure out how I want to organize my work, what resources I need, and most importantly, what interim deliverables to help me ensure I can build my MVP and it is what my target customers want.
Defining my process
Since this is a one-man show, you’d think I could just wing this part. However, my previous failures taught me that I need a rigorous process, even just to keep myself honest and accountable.
I’m using SCRUM to keep things simple. It is a process I’ve found to work and am already familiar with. This will define the main foundation for managing my daily work and when to review and update my process.
I’m using OKR (Objective & Key Results) to align my actions with my strategy. However, I’ve found that OKR doesn’t do a great job of helping you to break the objectives into smaller and more managible chunks. I’m incorporating the “12-week year” to address this gap, so I have aggressive quarterly goals, with monthly and weekly objectives and key results/deliverables.
So here is my process, i.e., how I’ll manage my work
OKR to break down my strategy into my big picture OKR: to successfully bootstrap a SaaS company helping people build better products, with key results of $3M annual recurring revenue and 80+% customer retention.
“12-Week Year” to define my quarterly and monthly objectives and key results will help me to deliver the larger OKR.
Weekly Sprint keeps me on track toward the monthly deliverables. Each sprint starts on Sunday and ends on Saturday, with Sunday as a pure ‘planning’ day which also gives me permission to spend time with friends and family.
Use the “Next Action” concept from GTD (Getting Things Done by David Allen) instead of user stories or formal requirements as a simple checklist. Since it’s just me, anything more will be an over-skill and not worth the effort. But if I do bring a team on board, they can be quickly translated into formal requirements, like user stories or something else.
Though I am the only person on the team, I still want a more formal communication process to speak with my future self. To do that, I am integrating the weekly scoring process from 12-Week Year and Retrospective from SCRUM to document what went well, what didn’t go well, and what I want to start/stop doing in the coming sprints.
Of course, if I had a team, I would focus more on the sprint and communication by turning the monthly and quarterly objectives into Epics and breaking it down into User Stories for the sprint deliverable.
Identifying Resource Needs
Building a web app is pretty inexpensive these days, especially since I’ll be doing all the work. Here is a quick breakdown of the expertise I need and what I already have.
Front-end development expertise, such as HTML, CSS, and Javascript, is needed, but I am very rusty (I haven’t done it formally for over a decade). So, up-to-date expertise is needed and missing.
Back-end development expertise. this including Data/object modeling, programming, building APIs, and so on. This is more in my wheelhouse and I won’t need the support I would with front-end development.
User Experience design expertise. Such as designing layouts and user flows. This is also something I have decent experience in but I may need to bring in an expert for advice.
I don’t need to worry about physical resources right now since I already have a PC (Mac Mini) and a home office.
Now, I have identified that I need to bring in some HTML, CSS, and Javascript expertise to get me back up to speed and maybe access some design experts to act as advisors.
Here is how I’ll fill the resource gap.
HTML, CSS, Javascript expertise → Claude by Anthropic, and O’Reily online
Design Advisor → My network of UX experts
Also, to reduce the number of moving parts, I will leverage Svelte/SvelteKit, with Postgres as the base framework to support both the front-end and the back-end server. This will minimize the places where things can break and the number of programming languages I have to deal with.
Milestones
Now, with all that out of the way, I am ready to sit down and figure out milestones to help me deliver against my roadmap.
Milestones help me track overall progress and identify the key signposts that tell me if I’m on schedule and on the right path and if I need to make changes to make up lost time or change courses altogether.
A good way to identify milestones is to examine what intermediary deliverables make up your larger deliverable and what assumptions you have made that need to be tested to make it realistic. With those in mind, here are my milestones.
Simple end-to-end proof of concept to test out the technology stack and gain familiarity with Javascript, Svelte/SvelteKit, Prisma (the DB connector), and SQLite. Focus on the most basic functions, such as creating key elements in the product.
1 or more working prototypes with key features and value propositions that I can use to conduct user testing and interviews. This will also allow me to layer on the features and slowly transition to Postgres.
Alpha release to test the deployment process and code stability and get broader user access as part of go-to-market.
Beta/preview release to test out the full end-to-end process, including connection to any 3rd party systems, such as payment and messaging services. This will also serve as the soft launch phase of the go-to-market process.
MVP launch!!
These milestones will help me track my overall progress and eliminate risks that could cause the product to fail.
Now that I have a process, resources acquisition, and milestones to work toward, I am ready to start executing my plan.
Subscribe to follow along, and let me know what you think of my approach. What would you do differently? I’d love to hear your approach to this, and tell me what I missed!