I was explaining my approach to feature planning in a talk with a teammate and realized it would be useful to have it written down for future reference.
For context: In Product Hunt, we work in sprints of 2 weeks. A developer works in Single Player Mode on a single project and has to deliver it at the end of the sprint. We can only extend projects in 2-week increments. This is inspired by Basecamp's "Shape Up". (I will write more about this in the future)
I start by answering the following questions:
- How can the project be feature-flagged, so I can work on it in isolation?
- What is the smallest thing I can ship and get feedback on?
- Usually, I start with designs and UI flows, without any backend for them
- What are the most significant risks and unknowns? How can de-risk those?
- Things like missing tooling, performance, external APIs, user flow, design
- What is most likely to change?
- It's a given that texts and design elements will change
- What are the most critical features for the project?
- What can be shipped in two weeks, and is there anything that can be cut?
- What is the definition of "done" for the project?
Those give me enough information to understand the project and to have enough context to split and prioritize my work. I use FocusedTask to keep track of my progress.
I want to show constant progress and de-risk the project.
- Ship feature-flagged code every one or two days
- Get feedback continuously from everyone involved in the project
- Don't focus on details in the first couple of days (or even the first week)
- Separate domain logic from plumbing code
- Design code like it will be removed tomorrow
- Keep the backend clean, especially the database models
The moment I even think that I won't be able to ship by the end of sprint - I say so and start a discussion with the rest of the team. We can adjust scope, solve a roadblock, or decide on a feature that needs a follow-up sprint.
I mostly use one of the following two formats for defining features:
List of event -> result -> next event:
Feature: Do you use this product
product page -> (not using) -> do you use? -> yes -> tips prompt?
product page -> (not using) -> do you use? -> no -> alternative prompt?
product page -> (using) -> edit link and tips prompt
I use this for more straightforward features.
For more complicated ones, I use a flow diagram (I use Whimsical for those):
I use this diagram as my progress bar or todo list. I mark different steps with colors to communicate their current development state.
- yellow is "work in progress"
- green is "done"
- red is "won't be implemented"
This was inspired by Domain Modeling Made Functional and the way features were defined as series of domain events.
Before sending my code for a code review from my team, I do the following:
- Write end-to-end tests - I find a lot of value in having tests which test the whole system.
- Self QA - Before sending my code for code review, I manually go through all of my scenarios (as a QA). I look for edge cases and errors. I often discover issues with project requirements while testing like this.
- Self Code Review - Code review my code as I would for anybody else. I try to put myself in the shoes of someone who hasn't worked on the project.
When I deploy my changes, I notify everyone interested in the project and collect feedback. I provide what was deployed and what the next steps in the plan are.
For some features, I provide video/gif walkthroughs.
This is my approach when I work on a project. I adjust it depending on the project and the process the team is following. The most important thing is to de-risk, and you can do this by getting constant feedback.
If you have any questions or comments, you can ping me on Twitter.