Uncharted Waters

May 8 2018   9:32PM GMT

Navigating Software Roadmaps

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

Tags:

Five or so years ago I was working at an early stage startup in the anesthesiology space. We were making a product for anesthesiologists to document cases in real time that would help them navigate away from traditional pen and paper solutions. The development team I worked with was building and delivering software one week at a time. The business was inventing and designing software 6 months to one year at a time. Once a quarter or so, the company would get together and listen to a meeting about our product road map. This told us about the customers that were important, and what software changes they would need over the next 6 months.

Seems nice to have that much certainty, right?

This team was working in a sort of agile process. Not agile in the sense that we had removed handoffs from the development process and could ship the minute a feature was pushed and green in CI, but agile in the sense that we changed quickly and easily. We had one large customer at that point, and several were on the hook for a contract.

product roadmap

One day, we had a new customer smelling around our company. They had a need for what we were selling, but also the completely new problem space of taking a large amount of old medical forms that needed to be reviewed, converted into a new format, and sent to a government agency. Being a young company in need of revenue, our sales people said “of course we can do that for you”.

We became a new company over night. We split our software development team into one group that was working on the core anesthesiology documentation product, and another that was working on a tool to review and submit medical forms for meaningful use certification. We also hired a group of people that were intended to take medical forms, review them for errors, enter relevant information, and batch forms for submission.

The business side of our organization, sales and product namely, got together to make a product road map. We had a meeting to let everyone know the new product direction and what we would be working on for the foreseeable future. This lasted a couple of months if memory serves and then we split the development team again to have teams working on an iPad app and another to digitally design and define forms.

The business side of most software companies want certainty. They want to know how many people they will need for the year, how much those people will cost, when something will be delivered to customers, and how to report all of this to investors or leadership. On the other hand, the development needs to be flexible, respond to uncertainty and a lack of information, and respond to technology and product changes as fast as possible. There is a tension between these two groups based on need for certainty and a real need to respond to uncertainty.

I don’t put too much stock in product road maps at this point. They might be good for illustrating what we’ll be working on for the next mont or two. They are also one big sale, or angry customer, or market upheaval from being irrelevant. Just like with estimates and card slicing, the further out the road map goes and the more ground it covers, the more likely it is to be wrong soon.

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: