/ productivity

Feature Planning

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)

Scoping

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.

Working

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):

Flow diagram as todo

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.

Shipping

Before sending my code for a code review from my team, I do the following:

  1. Write end-to-end tests - I find a lot of value in having tests which test the whole system.
  2. 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.
  3. 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.

Conclusion

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.