Surmising the Product Paradox
To me there is something more important than art and science. It’s in understanding how these two things intersect. For me, understanding the above makes for a better project and product manager. Great teams don’t hire for a role and skill set, they hire for the attitude and responsibility of delivering the whole product against quality. I think this is where most team’s can fail.
When a team fails due to a project or product under performing expectations. An example I use is when a website relaunch occurs when clearly its predecessor was better. Why does this happen? I surmise it’s due to a team lacking a product role, whom their duty is product integrity than the handful of assembled tasks attributed to a regular project and product manager.
This stems, in my view, from hiring. Teams fall victim to hiring for the role than hiring for the product. When you hire for the role, you inherit role resistance: preset patterns ‘x person’ has acquired that can go against the grain of building product regardless of any surface layering of ‘passion’ and ‘teamwork.’ You promote ‘over the wall’ mentality. At the end of the day, someone needs to own the product’s life during build, and that responsibility is the product manager, or project manager if their roles are intertwined.
A great product or project manager owns the product. Like in many agile articles, agile practices deteriorate without a clearly defined product owner. Project responsibility can occupy many seats, but the product owner guides project integrity with the delivery team, balancing delivery with business value. They must understand the art and science of domain language and behavior which defines a product’s requirements governed by business value:
- what is the problem and how does the solution answer it from a user’s behavior interacting with it?
- How are requirements decomposed into feature-sets and subsequently user stories which extrapolate business value down into the build and delivery?
- Why or why not is acceptance criteria testing behavior using given/when/then statements which translate expected function and nonfunctional behavior?
- When estimation is wrong, what’s the right way to split, pike, or punt the story into quality-measured secondary stories relating back to the feature-set (e.g. theme, epic).
This knowledge becomes tacit to the product owner. To have this member on your team takes an art and science quality. I think this person should split their skills 60/40 between business and technical. You merge the art of business case and the science of technical delivery. Together art and science guides product integrity, and a product or project manager of this capacity must take charge—but be hired in the first place. I surmise teams should hire this role to end the product paradox of hiring roles based on skill sets than product responsibilities.
If you don’t you end up with project managers managing tasks that don’t get delivered, and tasks delivered that don’t meet expectations. A critical sticking point to recognize is that tacit knowledge comes from contrast with the team. It won’t happen immediately, but soon enough your product owner can transform your build team into a well-oiled delivery machine.
__
Thanks to @imagemechanics for catching my typos and tweeting me about it. It was a late night.
