This is a continuation of a previous article. In that one, I tried to describe a project-oriented culture. These are more traditional in nature and, as I tried to illustrate, not that supportive of an agile mindset and execution.
What is a Product-Based Organization?
Not all of the below characteristics apply to everyone, but they serve to differentiate product thinking from project thinking and how those differences might impact your agile mindset and transformation success:
- Products typically don’t have a start and end at least not for a singular engineering build event. They may be retired, but that is usually after many build investments in their evolution. So, there is a longer-term view to the lifecycle of a product that much more accurately reflects typical customer usage cycles.
- Products don’t necessarily have to have an external direction. You can have a product focus with internally generated and support IT-based products as well. In fact, the dynamics are quite the same independent of direction.
- Products usually have an ongoing or continuous investment. The ROI is usually calculated for multiple instances of the products release AND for maintenance burden from one release to the next.
- Products support the notion of experimentation, learning, pivots, and MVP’s. Early on in the lifecycle, the product is often evolving quite quickly based on client and market feedback.
- Products are often created and maintained by a consistent team or set of teams. Of course, there might be normal expansion/compression of the teams during the life of the product, but a core team is maintained.
- In the agile community, you hear the terms – Component Team or Feature Team. These are indicative of the product area focus for the teams. In this way, teams become adept and skilled within certain product areas. This also includes special experience with the client’s needs and business domain.
- Products usually having ongoing specialized engineering focus for enterprise architecture and UX needs. Similar to the Spotify model of Chapters & Guilds, cross-cutting concerns are often ongoing as well through the lifecycle of the product.
- Products get ongoing care and feeding. You maintain them. You invest in them. You update them. All with an eye towards controlling the viability and reducing their technical dept.
- In multi-team product development, dependencies are acknowledged and embraced. Planning and cross-team work techniques seek to minimize and accommodate dependencies. This is where techniques like SAFe’s – PI Planning can be advantageous.
Is there a choice?
Meaning, if we’re trying to be agile, can we still have a project-based mindset? How about just a bit of one? We’re simply evolving, right? And agile is inherently flexible, right?
I actually don’t think so.
It’s not really about agile or not. It’s more about aligning organizations with a more sustainable and congruent model for product (internal or external) delivery.
Another way to articulate the difference is this:
Do you throw people together to solve projects?
Do you direct product work towards resilient teams who are capable of delivering solving problems for your customers?
My friend and colleague, Cory Bryan, recently recorded a Deliver It podcast focused on this same topic. Check it out here.