Creating a Technical Roadmap
Working for a startup has many benefits, our small size allows us to be nimble, make decisions quickly, and react quickly to customers needs. It’s not all gravy though. As a small team, your time is precious and this can encourage you to focus on the short term! There are, however, a number of events which can prompt you into planning for the long term. The new year, maybe? For Trail, a change in our sales team and funding has allowed us to reset our objectives for the next twelve months which is the perfect catalyst for a review of our Technical Roadmap.
A Technical Roadmap should follow from your Business Objectives and Product Roadmap. At Trail, I’m fortunate enough to work with a CEO and CPO that have a strong vision, meaning our business and product goals are well defined — without these strong markers in place, it’s almost impossible to prioritise a long-term Technical Roadmap. Once you have product and business objectives you can drill into them and work out the key action items. Roughly speaking our key objectives are:
- The number of customers our app can support.
- Best in class for UX and product quality.
- A drive to reduce overheads (encouraging a smaller team size to ensure efficiency and outsourcing our ancillary work).
- The saleability of our business.
- Our product goals.
We then took these objectives and broke them down into goals, further breaking these down into actions to understand where the critical gaps were in our technology, process, and even our understanding. Once we had a list of clear, low-level actions we could go through and prioritise them. To work out the most critical items we loosely scored them based on:
- The immediate value the change would bring to the product (performance, device support).
- The immediate value the change would bring to the development process — and hence, the delivery of the product (test execution speed, development tools).
- Potential impact on customer trust (disaster recovery, security).
- Potential impact on delivery (disaster recovery, etc.).
- …and, how the changes might impact our ability to scale http://oxfamblogs.org/fp2p/wp-content/uploads/2015/04/will-this-scale.png :)
The process raised a number of key actions which will be critical to our success in 2016;
- The need for additional load testing
- Improvements in our automated testing
- Gaps in our disaster recovery process
- …and greater definition for our hiring requirements.
The process also gave us perspective on our existing plans, steering us away from the ever tempting new-and-shiny-project’s if they weren’t aligned with our overall business objectives. Valuable work, even if our time is so precious!
