One of the keys to success for a great product person is having control of your backlog; i.e. knowing where you want your product to go in the next one, three, or six months. Agile software development doesn’t mean that you don’t have a solid plan for your product, it means that you’re flexible on how you get there.
For example, I live in New York, but grew up in Boston and often visit to see my family. There are several ways I could get there:
- I could walk (not the quickest solution, but it’s possible)
- I could take a bus (lots of stops, but better than walking)
- I could drive (faster than walking or a bus, but more expensive)
- I could take a train (fast, allows me to do work, but costs more than the previous options)
- or I could fly (the fastest, but getting to and from an airport and through security is a hassle)
At the end of the day I’m going to get to Boston, I just need to figure out what factors are most important to me: time, cost, or convenience. If cost were really the most important factor, then maybe I’d walk. If cost is just very important, then maybe I’d take a bus. If time is the most important factor, I will probably fly, but if it’s a combination of time and convenience, I will most likely take a train.
Deciding on your objectives first will determine how you accomplish the day-to-day steps that take you toward those goals. In other words, your objectives determine what your backlog looks like, which ultimately leads to success.
For those that are new to Agile, your backlog is a list of prioritized “user stories” that your team will work on. User stories should always reflect the following; 1) the group the story represents, 2) what is being done for that group, and 3) the value that the story will bring. For instance, “1) As a traveler, 2) I want to go from New York to Boston in the quickest possible manner that doesn’t inconvenience me or cost too much, 3) so that I can visit my family.” When you have all your user stories in place, your backlog will be in order and it will reflect your objective and your goals.
In order to be successful, you need to know where you want your product to be in the short, near, and long term.
To help with this, and to make my life easier, I like to practice the 80/20 rule.
The 80/20 Rule
The 80/20 rule is pretty basic. As a product person in an Agile world, you should spent about 80% of your time focused on the long term and 20% of your time focused on the short term.
The 80% is taken up with thinking about where you want your product to be in three to six months. You should focus on:
- What problem(s) are we solving for and what is the value to the user? (It shouldn’t be a list of features, it should be a list of the ways you’re helping the user.)
- How does this fit into the bigger picture? (That is, making sure that your product fits into the user experience and your overall business.)
The 20% should be spent making sure that your team is focused on the current sprint, and that you have the next sprint pretty much locked in place. You should focus on:
- Does the team understand the product plan? (In other words, the value that it’s providing to the user.)
- How are we going to solve the problems? (How are we going to deliver that value?)
Without understanding the 80%, your 20% becomes incredibly “noisy” and distracting; your team will lose focus, your product will suffer, and you will end up with ad hoc, quilt-like software (a whole bunch of little things that are stitched together to make something inconsistent and random). The more research you do and the more you understand your users, the easier it will be for you to recognize the problems you should solve.
The more you understand the 80%, the easier the 20% becomes. Focusing on the 80% creates a higher “signal-to-noise” ratio and will lead to a more successful product.
