The Lean Startup by Eric Ries should be required reading for any person contributing to the creation of software (or other) products. While the focus of the book is entrepreneurs and startups, Ries rightly points out that even if you work within a company, you can adopt an entrepreneurial mindset and the lean startup process. An intrapreneur.

In particular I have been incredibly interested in the "Build Measure Learn" (BML) loop. Having adopted Agile where I work, coming from a traditional waterfall background, I feel as though our particular flavour of Agile sits primarily in the "Build" phase. While Agile has holds the Retrospective as an opportunity to learn, and has the Burndown as a means to measure velocity, it feels much to me like that learning is limited to development and the rituals that lead to development work being allocated. The application of measuring and learning about the product, market, customer and how that fuels development is largely ignored. The Lean mindset applies the build/measure/learn method to the entire cycle. This, while obvious when you read it, feels very much to be missing from our own development cycles.

I work in "IT" at a fairly traditional company. In the company structure, there is a divide between "business" and "IT". "Business" makes the money (the product is not software) and IT is there generally to support or enable the business. Agile advocates to bring the two groups closer so that the business can be directly involved via the product owner, write stories, prioritize the backlog and be more engaged in product creation. However, while this relationship begins to traverse the divide, I feel this structure disincentivizes IT from adopting and advocating for the tighter, more nuanced improvements products and customers demand. You get what you tolerate and my feeling is that unless IT in so-called traditional companies step up to actively feed and contribute to the BML cycle, the products and means by which they are delivered will always be lacking in some aspect.

Agile focuses on delivery - delivery of working software specifically. But what good is delivery of a functional product that does not deliver true customer value? Successful products require alignment of business model, incentives, product-market fit all wrapped up in effective software delivery.

Whether there is an IT and business, or both or neither, it does not matter. If you are building software products that are not paid for by the consumer or are only used internally, all the more reason to focus on the BML cycle in order to understand the true value you should deliver.

Even if you do not buy the above arguments, I think it would be wise to accept that you need build measurements, metrics and validated learnings directly into your product process. If you are not able to answer the questions required for business to answer value questions, how, as a professional in the workforce can you effectively evaluate your effectiveness or the value you generate?

The further I progress in my career, the more I realise you need to OWN your work like never before. Even if you are not a founder, a CEO, a manager or project lead, you would do well to consider yourself the CEO of your own value generation. If not, how can you value or shape your own progress?

To some extent, reading The Lean Startup has been as revelatory to me as when I was first introduced to the nature of functional and dvisional organisations. Working in a functional organisation serving a divisional one, it became clear that many of the frustrations and challenges we faced were not unique, that is to say, caused by our business as much as a lot of it is inherent to the structure. Divisions, by their nature only see or appreciate what is relevant to their division as that is the direction the incentives are aligned. As you begin to understand the structures, cycles and challenges inherent in the chosen setup, it really helps you identify what can at times be difficult to understand without the framework on which to hang your view.