When you are building a start-up, you are trying to create value around the asset. Obviously, job one is to be all “MVP” and “build something customers want”. After that – after you have done the impossible job of building a business – something that looks a tiny bit like “traditional” product management starts to appear. Your product has to evolve and certain decisions about what to build next need to be made.
Today, much of this is solved via “user stories“. User stories capture what users will do with the system and how that creates value. The goal is to separate what needs to be built from how to build it. While this is a noble goal, it can actually interfere with the building of the value of the asset: In certain situations, the goal is not just to solve the users problem, but “lead the industry” or “map to a potential acquirer’s reference technology architecture”. In these situations, the “How” it is built becomes just as important as the problem being solved.
The only cure for this problem is tight linkage between business and technology. Just as a user story is an invitation to have a conversation around a user problem, that invitation must encompass the larger “how”. Of course, that presupposes that the business has some inkling of how technology approaches build business value.