When I joined my current company, I heard a couple recurring themes in my first few weeks of meet and greets. One of them was that no one trusted the product and engineering teams. Software rarely shipped, when it did, it was buggy, and there wasn’t a lot of clarity about what was being built and why, when customers were asking for something entirely different.
It quickly became clear that job #1 was not going to be product strategy but rather building a functional product engine that delivered results. It didn’t take long (months, not years), and you can do it too.
Here’s the 4 step process I used to rebuild trust in the product and engineering processes with my stakeholders:
Step 1: Listen a Lot, then Talk a Little
I started where I believe any good business relationship starts – with communication.
I instituted biweekly syncs with our VP of Customer Success and VP of Sales to make sure our biggest customer-facing teams were being heard.
I started monthly internal blog updates with progress from the last month and the plan for the upcoming month.
We became more responsive on chat and acknowledged bugs as they were reported, even if the answer was, “we’re not going to fix that right now.”
Step 2: Cut Down Product Requirements
We were in a cycle where because we never shipped software, the product team piled on unrelated or unnecessary requirements whenever the team was touching a part of the code. They knew better than to balloon the scope, but they were fearful if we didn’t squeeze in that requirement, it likely would never get done. They weren’t wrong, but rather than demanding a better way of working, they let the broken system break them.
We took a hard look at what we were asking of the dev team and became focused on creating requirements that were the minimum piece of functionality we were willing to ship – the thinnest vertical slice where someone could find full value in the product. Turns out, my up-and-coming product manager is brilliant at this. To this day, he challenges me on keeping scope as lean as possible and reacting to customer responses.
Step 3: Underpromise and Overdeliver
It takes an experienced project or product manager only a couple of months to deeply understand what their dev team can deliver in a certain period of time. What? A couple of months?! How can it take that long to answer the question I get at least once a week? “How long would it take to…”
A few months really isn’t much time when you consider what goes making into a solid estimate:
- Understanding your development and release processes – how hard is it to get code out the door? How much is automated? Are there times of day or days of the week when you shouldn’t release new code?
- How does QA happen? Is it manual or automated? If it’s manual, who does it? How much of their time is dedicated to testing?
- Understanding your technology landscape – which technologies are you using, and how do they impact the timelines? Where are the skeletons buried in the app? Which parts of the code haven’t been touched in a year or more? How much test coverage is there?
- Getting a sense of the team’s productivity and rhythm – how much time is spent productively in a week? What is the sprint and meeting cadence? Are the team’s days optimized for a “maker’s” schedule or a “manager’s” schedule?
- Where is the product scoping and design process in relation to development? Are they sufficiently far enough ahead to have requirements well defined when the team is ready, or is there a lot of in-the-moment decision making? Note: I don’t think this is bad as a rule unless it gets out of control…I feel strongly about the dangers of documentation.
Once a PM has a grasp on all this, it becomes somewhat easy to predict how much the team can deliver and by what date. It becomes increasingly easy every time you touch a new (to you) piece of code, as you learn how well-understood it is by the current team and how well-supported it is by your current processes and infrastructure.
Nearly 3 years in, I can give off-the-cuff estimates that I am comfortable putting in a customer presentation. But in the beginning? I still got those same “how long would it take” questions, but my answer was consistently, “I don’t know yet.” If you set boundaries with stakeholders and show that you can dial in those estimates over time, you buy a lot of goodwill in the long run.
During those “I don’t know yet” months, I would work with developers to create an estimate, then pad it heavily, and work to overdeliver. No one likes a long timeframe, but I’ve found that they like missed estimates even less. It’s worth the short term pain to set proper expectations and retrain the organization about what it takes to build and deliver software.
Side note: Dev processes can and often should be optimized. It takes a strong engineering leader to recognize inefficiencies and the path to fix them. It takes an even stronger product-engineering collaboration to commit the time necessary to bring the development processes to a point of maturity and automation that will benefit everyone in the long run.
Step 4: Project Confidence – Even When You Don’t Feel It
I was in the lucky position of walking into the company fresh and was able to “demand” the benefit of the doubt for a while. This isn’t available to every product leader, but I took advantage of it to the fullest. I projected confidence in my ability to scope, design, and deliver working software partly because I knew the company needed something to believe in, but also because after 10 years of doing just that, I knew I could do it here.
If you’re struggling with this one, watch Amy Cuddy’s TED talk on faking it til you believe it, and then watch it again. There is no more powerful confidence booster than simply doing the work until you no longer doubt that you can.
