The Coral Reef of Product Development
Joining Stash in January has given me a fresh look at how product fits into the entire ecosystem of a company. I’m already starting to see how each team influences each other and how we go from ideas to shipping features. As a new person in a team of ~35, it’s an ecosystem where a big change in one place can make a significant impact somewhere else. Here are 3 things you might want to keep in mind as you work on your own product development cycle.
Don’t ignore the big stuff
The sheer number and scope of all of the ideas thrown at the Product team can be overwhelming. Flashy things and business-as-usual can keep you treading water, but at some point you’re going to need to ship something major. And if you don’t pay attention to the big stuff, you’re going to get caught when there’s blood in the water.
Find a way to organize and collaborate on your backlog of specific ideas, more general outcomes, and other opportunities. We’re currently using Trello, but you can use any number of tools, as long as you:
- Make sure everyone (including Customer Service) on your team has access to it. Always point back to it when discussing ideas so people can contribute and see ideas move and develop.
- Prioritize by factors everyone agrees on. Using our top 3 KPIs to prioritize ensures we spend the most time on things the whole organization needs to improve. Everything else is just less important.
- Don’t sweat the long-tail. Spend some of your time each week going through the rest of your backlog and figuring out how to weave it into your extra bandwidth. It’s more important to capture and collaborate.
Size often to reveal true costs
Pressure to commit to deadlines and ship projects can happen way before the most essential details are figured out. You’ll find yourself with dates that are impossible to hit, and a team that treats every “ASAP” project with the same low level of urgency. This can create a vicious cycle of over-promising and under-delivering. You have to uncover the real costs of every project before it’s too late.
We have weekly backlog reviews with each engineering team to size out tickets, so that we can make prioritization decisions before we get to sprint planning. This allows us to more accurately size projects and reduce scope before we actually commit to a project. I would highly recommend starting these if you’re not doing them currently.
Give yourself time to clean & test
QA is insanely difficult to get right, but it’s worth it. Every time you find a bad bug and have to rush a fix out, remember it could have been avoided if you had taken some time to assure that the new stuff you’re shipping won’t break your most crucial flows. Consider it a last tune-up before your app swims out into the open ocean.
We’re currently using a mix of Applause and in-house testing to do proper QA as the last stop before we release. We’re working towards more automated acceptance testing in the future, and experimenting with better release planning so we avoid headaches as we scale.
Ultimately, you have to start somewhere. Do your best to design good foundational processes that will evolve as the company grows and changes.