Reid Manchester, Product Manager at Bestpass, delves into the experiences that he’s had in dealing with trust and risk in product management. 

---

Do you sleep well at night? Or are you restless, and worried about your product’s health and success? If you join me in the latter category the reason may be related to trust and risk.

It recently became clear to me that to build healthy, successful products, product people simply must operate in a state of low trust. Why? Because of risk. Risks seem to surround our products, residing in teams, people, technology, processes, and more. Constant vigilance must be brought to bear, coupled with a sixth sense that sniffs out risks and stomps on them before they affect the product.

Good digital products have a high up-time, are highly responsive and users rarely encounter an error. To get to this idyllic state, I recommend dropping your trust level 50%.

Forget those trust fall exercises you participated in as part of team-building workshops, because you, my product friend, are the single butt to be kicked when your product fails. Do your trust fall exercises with full faith, and then return to the office with a healthy skepticism and suspicion. Let’s talk about the experiences that brought me to promote this operational model and the lessons learned from each story.

You got your chocolate in my peanut butter!

The title here might predate you, so here’s the reference. Do other teams orbit your product and share your technical ecosystem? How much do you trust them?

Another product manager and I owned products that share a tech stack. We communicated regularly and I even attended her stand-ups on occasion (doing so daily would be a burden, I had my own to attend). ‘Sarah’ deployed a new version of her product. It was an incredible upgrade to our payment processing functionality that was badly needed. Its value was inarguable.

Unfortunately, our products shared an API and her upgrade to the API didn’t take into account a tiny customization created for my product. Suddenly, my consumers couldn’t submit payment. The result? Nothing good, and a small fix took a week because our company wasn’t running DevOps. I’m not blaming Sarah; like many of our fellow product managers, she’s highly competent.

What options did I have to prevent this situation? Should I have inspected her team’s work in detail, examining risks to my product? Should I do this for every product in our stable? That’s not reasonable. But automated testing of my product against that API would have caught it. Heck, just ONE manual test would have caught it.

Lesson: continually test your product, and maintain technical documentation that covers special configurations and what can impact them. This reference material can become a checklist to be used before deployments. I’ve learned that a single manual test before a production deployment of someone else’s code branch can do wonders.

Solution: This event spurred me to create a comprehensive tech stack diagram that identified all customizations and interactions with other products. It allows you, in seconds, to trace the downstream effects of a change to an upstream system. Building it is hard work and maintaining the mappings is even harder. When done in diagramming tools like draw.io or Gliffy you can apply hyperlinks direct to a JIRA epic or story that lays out the technicals in great detail. This allows anyone in the company to examine possible breakpoints and risks.

Stop sending me texts!

Here’s a case study in trust: for several months I was hearing that customers were complaining about receiving unexpected text messages from my product. Extensive investigations yielded no root cause. As the onshore team that built the SMS feature had long ago moved on to other projects I decided that the right solution was to move to version 2.0 using an offshore team: introduce new text message alerts and while you’re at it redesign the rules governing text message campaigns.

It felt good to have a low-cost plan that brought value to the feature. However, when the new logic was deployed it triggered 700 text messages to be sent in error (followed by a further “oops” message of apology). This debacle resulted in some onshore team attention, with one expert diving in to evaluate the mess. Within minutes the expert identified the root cause of the original errant texts and the 700 just sent: a development environment with production credentials was sending the texts.

Must we as product people be prophets who can forecast a wide variety of undesired outcomes? Must we be sleuths, performing research and investigation?

Lesson: we are product managers. But we must also perform a project management function, cogitating on extraordinary risks introduced by others. Some deep risk assessment prior to the deployment of the SMS feature might have identified the need to erase those production credentials.

Show me the UI!

During a sprint demo, how often have you said to yourself (or out loud) “that’s not what I asked for” or “that’s not how I would have done it”? I hope this is rare for you, but this commonplace event is a serious inconvenience for product managers because the feature has essentially been delivered and it could be another sprint before the feature is corrected.

You may be thinking that this should never happen if proper requirements research is completed and the requirements are comprehensive and clear. Such shortcomings would of course be the fault of the writer of the requirements. What if your requirements creation was delegated?

Some time ago I tasked a junior UX designer to provide the developer with requirements in the form of screenshots with new directions. In the image on the left, you can see what the designer sent: the instructions are in a bubble at the top, and not in a coloured bubble at that. This direction is obviously inadequate and confusing. On the right: what we got back from the offshore developer. The developer integrated our instructions into the UI verbatim without thinking or asking for clarification.

Lesson: insist on being shown the UI before it goes to QA where more time will be wasted. Another win for the low state of trust, as I caught this one before production deployment.

It’s been a year. What do you mean by “it’s not done” ?

Rarely does a product manager have all of the resources necessary to deliver a product. Most of us must rely on other teams in some way. Architecture, operations support, customer service, and finance are just some examples.

How often have you added a work item to another team’s queue and trusted that it would be done in a reasonable timeframe? If you answered “none” you’re smarter than I am. Once upon a time, I created a work ticket to alter the way in which we handle credit card retries for failed charges. This ticket fell under the scope of production support — a team that I have limited influence over. I later discovered that the item had been sitting untouched in the queue for over a year.

Lesson: assume that another team will not address your work items without the application of some pressure and your presence at meetings.

Wrapping it up

These stories begin to create a pretty solid case for product managers to exist in low states of trust. We often see risks that others can’t. We’re a single butt to kick when things go wrong. The unfortunate reality is that operating in low-trust states is exhausting. Taking the role of a single highly responsible party is tough. Just ask any politician or executive. What can we do to make our lives a little easier?

Software products tend to be pretty complex. There are endless edge cases and exception scenarios to cover in the planning and execution phase.

Unfortunately, product management responsibilities don’t end with planning and execution. We’re tasked with deriving value from a product over its entire lifecycle and this means that we must consider risks to our products on a daily basis.

Perform risk assessments, and do it frequently. When you and your team can’t identify any risks it’s clearly time to invoke the tenth man. This concept comes from the movie World War Z. When the team looks at the product, tech stack or code branch and sees no risk, the tenth man (in our case an outsider) is responsible to disagree and push for risk identification. This person is ideally aware of broad technical changes taking place in the ecosystem. Given time and practice, this exercise can vastly improve up-time and pay serious dividends, especially when the tech infrastructure is complex.

Take the Ronald Reagan approach: trust, but verify. When you identify a possible risk and someone deems it low risk or discounts it entirely, perform your own due diligence.

If you’re wondering if there’s a psychological impact of existing in a low state of trust, there is. The web is peppered with blog posts and articles with titles like “Why I left product management” (Google it and see!) and, most creatively, even some spoken word poetry about the dizzying complexity and wide array of demands on a product manager. It’s wise to set some systems in place so that you sleep better at night.