The Seven Habits of Highly Effective People by Stephen Covey is probably the book that had the most overall impact on my life. Other impactful books mostly touched my professional life. This one not only did that, but also changed my life outside of work. It impacted my character.
Creating a product vision is not overly complicated, if you keep three things in mind. Start with users, involve others, and write it down.
To me, there seem to be six characteristics that describe any well crafted product vision. Many more exist but the following stand out to me in describing what a compelling vision is.
A product vision is of paramount importance. This seems to be a given. You can find a lot of material that simply states this as fact without explaining why this is the case. Many write about what a vision is and plenty of folks provide frameworks or methods for creating a product vision. However, rarely do they explain why the product vision is needed, what the reasons are for creating one. It seems to simply be assumed that everybody already knows. Why is it so important?
All companies know their What. It is what they are offering, the services and products they are selling. Some companies know their How. It is how they are building and offering their products and services, their values, their culture. The how is often also called Unique Value Proposition (USP). Only the rarest of companies are able to actually say Why they are doing what they are doing, what the real motivation is, what their purpose is
Agile is not Scrum, Lean, Kanban, DevOps, Extreme Programming, or any other agile method used in modern product development. Don´t get me wrong, all of these frameworks have a reason for being. I am working as a Scrum Product Owner (PO). We are successful and I thoroughly enjoy using this method. Scrum is one way (of many) to manifest and formalize agile principles. It is not equal to Agile. Agile development is a mindset centered on principles.
I recently wrote about the core competencies of a Product Owner (PO). Within that text I didn´t address technical skills. This topic is large enough to warrant a dedicated post. Well, here it is. Does a Product Owner (PO) need deep technical understanding to be successful?
In my view, the short answer is a clear NO for the vast majority of products. The long answer is a bit more nuanced: it depends. Overall, I do believe that technical understanding for a PO is a net positive. However, it can also lead to some negative outcomes.
I will dive into the pros and cons first before addressing some general points.
Besides Scrum, Kanban is probably the most prevalent system for managing workflow in agile product development. It is a very flexible system, with little overhead. As such, Kanban is very easy to implement. Many enjoy the feeling of flow that results from using a Kanban system.
To me, the sprint review is an extremely valuable ceremony. The principles behind the session itself are powerful, universally true, and can be applied outside of Scrum as well. Nevertheless, I feel that the goal and the importance of the review is sometimes misunderstood.
have read a few books that had a significant impact on my professional (and personal) life, maybe none more so than “Getting Things Done” by David Allen and “The 7 Habits of Highly Effective people” by Stephen Covey. However, a few months ago, I discovered the work of Cal Newport and read his book “Deep Work”. Its impact on my thinking was and is on par with the classics listed above.