TL;DR: Projects ask teams do what is asked of them; Products ask teams to invent their work. This requires a different way of seeing the world, and not everyone can do it yet.
Software is not an up-front investment that pays off over its use. Software is an ongoing concern, an intricate piece of a business that needs to evolve if the business is going to.
The current “Projects to Products” movement recognizes this. Projects are completed and delivered and then done; Products continue a relationship with their stakeholders.
Teams developing Projects add features to meet requirements (or “user stories”). Teams developing Products support capabilities at required performance levels, learn what else is needed & gradually support more capabilities.
You can tell a Project team what to do. You can advise and make requests of a Product team; the team has the deep knowledge of the software needed to decide what to do next. — that’s the ideal we sell.
What happens when you ask a group of people who are successful at writing the features you require
to own the product, notice what is needed, measure performance, decide to proceed?
I don’t think the same people (at the same time) can be good at both.
“The employee who must look to the employer to lay out the objectives, provide routes to their accomplishment, and evaluate whether the work done is of value…. contrasted with the employee who is mindful of the employer’s views and takes them into account, but who also has his or her own contribution to make toward understanding the goals, planning for their accomplishment, and evaluating the outcome.”
Robert Kegan, In Over Our Heads: the Mental Demands of Modern Life
The difference between people good at receiving direction and people who generate their own direction, according to Kegan, is not a personality trait or a skill. It is a way of viewing the world. An epistomology, an “order of consciousness,” a “gradual development of psychological complexity,” a way of defining yourself.
Kegan says, during adolescence we learn to see other people in relation to us, and come to define our self through those relations. This includes the employer-employee relation. We get loyalty and consideration for others. We get ideals and values.
Once we get there we’re adults. Later, some adults come to see those relationships in relation to each other, to decide which ones have priority in a given decision. We make tradeoffs between ideals, we generate values.
Both are valid ways of being adults, and both are moral and useful and good. But people hired and promoted to develop features are not the same people who want to influence direction of a capability.
Fortunately, we’re not asking people to do this, we’re asking teams. Teams can create the structure to give direction to people who need it, and support people who are moving from I-exist-in-the-roles-society-gives-me toward I-invent-myself-in-the-roles-open-to-me. Toward our self as our own Product instead of our culture’s Project.
I don’t know how to create that structure within teams yet. Maybe Kegan will have some hints later in this book.
If your organization wants to move from Project to Product, and people are confused and frightened by this, it’s not their fault. They’re not “resistant to change.” Taking care of software as an ongoing concern demands a new way of viewing the world. This might be easy for you, and currently impossible for others. It’s gonna take a lot of care and support to get there.