Software as a Product, Part II

I’ve heard a lot of talk lately about everything being a project. That’s fine when it comes to defining a particular scope of work and finishing it properly, but I do think that it could prohibit thinking about the big picture and long term strategy.

A product manager position can alleviate this issue by defining the project in terms of the overall product at large. This includes framing the project within a product road map, and ensuring changes in the project account for anything that may be coming along down the road. Most teams don’t have a technical product manager, so I would argue at the least, you need that road map with a fair amount of detail. It is okay that those details get fuzzy the further out in the time line you get, but at least periodically you can step back as a team and evaluate the overall direction that your product is taking.

I do like working on things that have a definitive start and stop, I just wanted to say something regarding aligning with a longer term software strategy. Dan Bricklin has already talked at length about the replacement cycle that most software follows:

We need to start thinking about software in a way more like how we think about building bridges, dams, and sewers.

Every piece of software we create, we should be thinking of its bigger picture: How does it integrate? How is it affected by OS and DB updates? How does this method play in our long term API strategy?