Product Intangibles: Minimum Viable Process (A love letter to Pivotal)
hint: it's feedback
Successful product companies share two traits: their product development teams know how to "build the right thing" (i.e. focus on customer and business outcomes), and "build the thing right" (i.e. focus on the craft of product development). This article focuses on the latter.
Recently, many discussions have been arguing in favor of specific processes or frameworks as a response to growing skepticism and frustration with Agile methodologies. However, the problem with these arguments is that dogmatic frameworks will never capture the unpredictable, deeply contextual nature of what works to build software right. Agile will never be effective if it's treated like a procedural process.
Iterative, incremental, agile development is still the best way to build software right, but strict processes and frameworks don't really matter. What works better are values and principles that emphasize flexibility while allowing teams to focus on their craft. Dan North argues in In Praise of SWARMing that "packaged scaling methods are neither necessary nor sufficient" and that the better, albeit more difficult approach, is to scale without a religious methodology.
To echo Dan’s sentiment, I propose the right way to “build the thing right” ****is WWARMing (working without a rigid methodology).
Practicing at Pivotal taught me how effective values and principles are at guiding good product work.
Everything about how we worked was guided by disciplinary expertise, a mission statement, and a set of 3 constantly referenced values.
Do the right thing
Do what works
Be kind
These values were top of mind for everyone, not just in a leadership pitch deck. Never before or since have I seen values manifest so tangibly or shape mindset and culture so viscerally as they did at Pivotal.
While devoid of any real detail or instruction they resonated immediately, broadly and deeply. Hearing these on day 1 and seeing the Pivots (what we called employees) next to me live them made it easy to embrace them myself. Values were the bedrock of a truly special culture. On the simplest level the words make sense. On an experiential level, they just worked.
That place thrived on a mix of extreme ownership, craft dedication, and autonomy at a level I haven’t seen anywhere else come close to. Many times I witnessed former clients join Pivotal Labs and be shocked by how deep-seated the shared mindsets went. It made a strong impression on me that (a) people thrive when they are openly encouraged to think critically and autonomously and (b)how impactful values and first principles are for building amazing products.
With many clients there was an attempt to codify the “secret sauce” so they could preserve and scale it. They would ask for playbooks and decks, buy Lean Startup by Eric Reis, and put up Concourse build monitors among team areas with desks in hills or valleys. They created process flows and bought piles of sticky notes. But they never realized they were looking at it from the wrong lens.
At Pivotal, the “secret sauce” was that there was no prescribed process to distill and bottle, only dedication to disciplinary craftwork and 3 values. Just enough to allow healthy norms to develop and keep everyone operating within the same value boundaries and unimpeded as individual thinkers.
Recent skepticism surrounding agile methodology is understandable. New best practices and processes have been developed rapidly to introduce and scale en masse, but this has not been accompanied by a corresponding focus on developing the mindsets necessary to sustain them.
However, to me, the only thing that the last two decades of trying agile has invalidated is the way we teach it, not the concept itself. Expecting process and templates to do agile is an anti-pattern. If we want to see high-quality product work at scale, we need to focus less on process playbooks and instead prioritize shaping mindsets and fostering craftsmanship.
There is a reason the authors of the Agile Manifesto left it at principles. "Building products right" requires a foundation of shared values, principles, and dedication to craft, not dogmatic processes.
I propose to “building the thing right” you need:
A default shared Mindset / expertise among team members
Values and principles that guide the practices and behavior
Constraints that empower autonomy with minimum limits
Agile craftwork requires constant critical thinking to adapt your approach based on the team and situation. This is a very difficult notion to learn through observation or diagram. Hell, if you look at a “process flow” of Waterfall vs Agile they look essentially the same, Agile is just condensed.
If you’ve worked on a mature product team that knows how to build the right way you know there are no cleanly defined steps like it appears in the above diagram. It’s much messier when done right because it depends on a high amount of directional alignment, communication, and work transparency that makes concrete steps and handoffs moot.
You don’t get new information from all sources in a predictable way, which impacts how you might prioritize and then do the work. It is chaotic, and the only way to build it right is to accept the uncertainty and use fundamental expertise to take the information you have, when you have it, and make a decision to go left or right.
The most mature practitioners and teams use shared values over process. You can’t really draw that out in a way someone can follow predictably.
Shared mindsets work best when they come from existing expertise
There is nothing wrong with starting from an existing methodology or framework. Framing shared mindsets from a known place means you establish a default way of working. The danger is allowing the default to become inflexible and procedural. Pivotal’s disciplinary defaults were Lean Startup for product management, eXtreme programming (XP) for development, and User-Centered Design for design. For each default, the craftwork done was flexible and evolving. Matthew Parker explained it to me perfectly:
“we had a nonnegotiable way of working that everyone opted in to because they loved. And so we had tremendous focus around improving our craft, centered around those XP engineering practices. That focus made us bad ass.”
Beware the efficiency mindset
Many companies default to an efficiency-oriented mindset that is opposite to what is needed for building the right things in the right way. If you want product-led work to thrive, you cannot expect teams to achieve it while being surrounded by efficiency-oriented expectations.
In his newsletter, Feature Factories vs Value Generators, Itamar Gilad illustrates the risks of an efficiency-focused approach to building things. He argues that Feature Factory teams (which are not the ideal way of working) create unsustainable hidden costs by keeping teams at 100% capacity and churning out features that lack real value, resulting in a product that costs more than it's worth.
This efficiency-oriented mindset has been the norm since the Industrial Revolution when efficiency became a significant competitive advantage. Therefore, most companies are primed to work like this by default. Unfortunately, most of us were born into and educated in an economy that favors the wrong mindsets for product work. Many Feature Factory teams operate this way because their companies, managers, or leaders have an efficiency mindset that defaults to maximum capacity, standardized processes, and an expectation that anything done outside the process requires permission.
Building the right thing in the right way requires a shift away from the default mindset of the past and towards values, principles, and directed work that enables flexibility and autonomy.
Structure values to be directional but not prescriptive
Every company has its own culture and values that set it apart from the rest. Investing the effort to carefully uncover and understand the values that are most important to your team(s) can help you create a culture that will sustain and thrive as your company grows.
You'll know you've honed in on the right set of values when they are broad yet tangible and practical. They should go beyond merely stating what to do and instead explain why it is important. Good values build on existing shared intuition, allowing them to become an embedded part of the culture, and leading to a deeper understanding of their purpose.
Establish principles that lead to reinforcing behaviors and culture
Even with shared values, different teams will simply do their best work differently and principles are what defines what a team’s best working style looks like. Shared principles should make it easier to do the right thing instinctually.
Broad values are important because they allow teams enough flexibility to make them their own and find unique principles to guide them. Pivotal’s 3 values did a fantastic job of this. Every team worked in a slightly different way but if you knew the values you could pretty easily figure out why it was right for them. Of course most teams had some of the same principles, for example:
Principle of transparency: unless there is a good reason, everything is transparent by default. Most teams were opinionated towards trust for teammates to make individual decisions. This principle made certain decisions easy. Slack for asynchronous messaging became a no-brainer because its public-by-default channels opened up all the conversations that would have otherwise been hidden in an email thread or meeting.
Principle of autonomy: share responsibilities to limit the handoffs and bottlenecks. To support autonomy, teams created ways to ensure everyone on the team (usually product managers, designers, and engineers) had equal understanding of business and user needs. Every person having the same understanding of customer needs and business problems made distributing decisions and responsibilities more fluid.
Use constraints to create minimal limits on autonomy
Where permission culture implies employees need to follow a process explicitly and only diverge if they have permission, constraining decisions is the opposite. If you set the right constraints everyone has the right to do what they think is best as long as it fits within what’s defined by the constraints set. Freedom to make decisions within defined parameters can be a great way to create trust and empower employees. For example:
Allowing employees with corporate cards to use it for what they need to do the job well up to a $ limit
Allowing engineers to make implementation decisions when building products as long as the outcome criteria is met
Pivotal spent a lot of time engineering ways to make it easy to do the right thing to encourage as much free thinking and creativity as possible. Work bounded by constraints vs laid out as procedure allows individuals to take ownership of their decisions and foster an environment of innovation. By implementing this kind of culture, companies can better structure their product development process and improve their workflows overall.
Building software in the right way requires more than a repeatable framework. Process is great for creating order from chaos. But creativity and innovation don’t emerge from that. Building the thing right requires risk-taking and leaps of faith, for which you need mindsets that enable critical thinking, flexibility, and autonomy.
The example of Pivotal shows that shared mindsets work best when they come from existing expertise because it creates intuitive, inherent norms and behaviors that allowed teams to build amazing products while thinking as little as possible about how, what, or why they did what they did. Values and principles create agility that enables agility without compromising what matters. Getting your teams ready to build the thing right is hard, but it is worth it.
Forget frameworks, work on mindsets instead.
For a real-world example of how values, principles, and constraints helped a real product team, check out the below: