Product Enablement Principles
A week in to my new role a Toast, I took some time to clarify my own principles when it comes to operations, enablement, and generally helping others. These may or may not become my team's principles, but it was a good exercise. Transitioning between jobs/roles is always a great time to reassess.
Happy teams, happy customers
Teams that are healthy, happy, have a sense of pride and ownership, and have the right mix of challenge and skill, are the path to happy customers. One is not more important than the other—they go hand in hand. Improvements that make customers happy at the expense of team morale are destined to be be unsustainable. Improvements that sustainably improve team effectiveness can move mountains on behalf of customers.
Principles before process. Why before way
Any process will eventually break (especially if you are successful). Any tactic will change. Start with principles, and you'll discover the right approach for the current challenge. This isn't meant to diminish process (see below), just noting that principles establish a strong foundation.
Partners, not stakeholders. Co-design the change
Whenever possible, co-design change experiments with others. They may have better ideas and will be more vested in their ideas. The more people you can get actively involved, vs. "stake-holding", the better. A big group of passive participants grinds to a halt. A small group of vested individuals can carry something forward. Work through others. It's not about you. Don't become the "figurehead" for any particular change effort. Let others take the limelight and represent the effort.
Trust is a huge force-multiplier
Remember the trust formula. Trust = (Credibility + Reliability + Empathy)/Apparent self-interest. These are your levers. Do credible work. Be reliable. Listen and connect before charging ahead. And don't make this about you. Trust is nurtured through promises regularly kept. It is an output, not an input. You can't tell teams "trust each other". But you can promote an environment where more credibility, reliability, and empathy can emerge.
Use safe-to-fail experiments
Consider 2nd and 3rd order effects. Consider risks. Assume things will fail. You deal with people's identities, careers, livelihoods, and well-being. Pick the safest experiments with the highest probability of yielding insights and progress. When in doubt, work to make what is happening now more visible ("Start with what you do now"). Don't get overly attached to the How.
Seek self-awareness and other-awareness
Know you'll go into any situation with your own probablies and justs. These are your defaults. When you're in a position of helping others, you'll need to 1) be aware of your defaults, and 2) be aware that other people have defaults. Don't assume you see things as they universally are, and seek to understand how other people are processing the situation.
Amplify the good—draw energy from the bad
One way to address issues is to attack "the problem". However, in many cases, you'll be better off amplifying the good and creating an "attractor" for new behavior. Focusing on a wicked problem is folly—it's there for a reason. Try, of course, but consider amplifying the good.
Limit change in progress
Teams and individuals have only so much cognitive energy available for change, uncertainty, and experimentation. Respect their bandwidth. We're biased to assume our thing is The Thing. It isn't. Team members are juggling countless things, and our ask is but one tiny part of their work.
Process is happening right now
Process is happening whether we acknowledge it or not. Sometimes it is very flexible and sometimes rigid. Sometimes it is intentional. Sometimes not. Principles (see above) are the ultimate process because they are very lightweight and fluid. People will say, "we can't solve this with process!" They are right and wrong. They are right that a simplistic, fragile, "robust" process will likely fail. But let's take a broader systems view—considering knowledge, skills, motivation, habits, and environment (information, incentives, tools)—and acknowledge that we're working in a complex adaptive system (CAS). We can artfully use "process" as a catalyst for improvement.
Explore, grow, and operationalize
Don't jump immediately to heavy-duty change management. Stay away from forever experiments. Teams get tired from being the test patient for tons of experiments. Consider your portfolio of bets. Figure out what works. Grow things that work. Then consider what to operationalize at scale. At any given time, you'll have "services" in all stages of maturity. They build on themselves—strong foundations and platforms help you launch and explore new things.
Good plumbing and platforms go a long way
When experiments have reached a stable place, consider the importance of good plumbing. You have to make it easy to do the right thing. At first, people will manually do stuff (you have the early adopters). But later on, you need to nurture the systems and tools that will enable everyone.
Challenge the need for consistency (or make it a lot cheaper and safer)
Standardization, consistency, and centralization are never free. And they are often not desirable. By default, question the need for consistency. When consistency IS desirable, work to make it cheaper and limit negative 2nd and 3rd order effects.
Seek leverage, always. Find a creative solution.
Don't brute force problems. Refrain from settling for things that scale linearly (or sub-linearly). Seek outsized results from lightweight interventions. Embrace simple solutions that are a good fit for complex problems instead of naively simplistic solutions that don't respect the situation's complexity. Challenge assumptions around "tradeoffs". Challenge "that's how we've always done it!"
Surf local and global maximums
There will be times when you KNOW the bigger problem is elsewhere, but there is an opportunity to improve things locally. Sometimes, the only path to the more significant change is local change, and sometimes not. Take this seriously. Refrain from dragging a team through the mud when it will have no/little impact. Address the global problem with care. Similarly, take the chance to improve things locally and expand over time.
It's all the product
How you document, how you support, how you educate, how you capacity plan, how you address legal ramifications, how you market, how you sell, etc., is ALL part of customer experience. In SaaS, the whole company is "the product". Product enablement is more than supporting product managers. We're supporting Toast, the product.
Think Big. Work small
Working small without thinking big sends you on a wild goose chase. Thinking big without working small gets you nowhere, and you chase big plans forever. Find the right balance—a bias for action and systems thinking.
Raise the red flag (with care). Pull the cord.
You'll encounter many acute issues—short-term stressors. Through a combination of help and support (and nurturing a resilient system), we can help teams absorb these stresses and come out the other side stronger. You will also be aware of "elephants in the room"—lurking chronic issues. If you think an acute issue risks bubbling over into a chronic problem or that a chronic issue is slipping backward, it is your job to call it out respectfully (and tactfully)
"Principles before process. Why before way"
This is so important. I've shared with my team the idea of playbooks over prescriptions which is a similar message.
Great post. I think these are very effective principles in general to work across cross-funcional, problem-solving teams and not only for produt enablement!
Just curious on the - process will break and tactics will change, so start with principles. But, would you say in the long run, principles could evolve (subtle for change) as well based on changing of context of a product/team/organization?