The easiest way to increase productivity
is not what you think....
It’s not the 996 work culture. Not aggressive deadlines or rockstar hires or motivational speeches. The easiest way to increase productivity - and the most overlooked - is simply this: reduce the time it takes to make decisions. Whether you’re managing ten people or ten thousand, decision-making velocity trumps almost every other productivity lever you can pull. In this post, we’ll look at the most common sandtraps that teams fall into that slow down their decision-making speed.
Before we get into the scenarios, it’s worth exploring why most teams and their leaders don’t dig into this aspect of running businesses. I’m sure that most of you, after reading the opening paragraph, are thinking, “Yeah, this makes sense. Why isn’t anyone on my team actively figuring out how to speed up decision-making?” I don’t have a clear answer to that, but I have a few theories.
My first hypothesis is that the question of productivity, or lack thereof, pops up only during moments of stress. For example, a delayed project will invariably force the room to discuss, “How did we get here?”, “Are we having a problem with productivity?”, “Is the team working hard enough?”, and so on. When these problems are raised under stress, everyone is looking for a quick fix. It will take someone—usually someone with a broad enough purview, like an executive—to find all the stops the decision train has to make before it’s finalized and then figure out how to make the train go faster. Translation: it will take some time and effort to figure out how to find all the choke points and eliminate them. However, in the room, which is already charged with stressful questions, no one will present it as a fix because the fix will take time to implement. This is why teams default to some of the other choices when it comes to fixing projects, like cutting scope, moving people around, 996, etc. And when the time comes to do a retro on the project, decision-making velocity is very rarely mentioned because it feels like something that will take a long time to discover and optimize. However, that’s not true. Here are some common black holes, in no particular order, that will eat away at your productivity and how to fix them.
What to build - If you ask anyone their opinion on how a specific feature should work, I can guarantee you’ll get a million different opinions and a thousand conflicting ones. Heck, you’ll get conflicting points of view even if you ask your customers that question. In my experience, when teams attempt to take a democratic approach to determining how a specific feature should function and the nitty-gritty details of its various knobs, bells, and whistles, they unknowingly sacrifice a great deal of velocity.
People often mistakenly compare building features to building a house. You won’t build a house without the wholehearted approval of the future owners, right? Building software features is not like constructing a house, but rather like drawing on an Etch A Sketch. If you don’t like the drawing, you can change it. You can either spot-fix it or erase the whole damn thing and start over.
If you’re a product development leader trying to figure out what to build, I recommend having a strong point of view on what the feature should look like. You should base that point of view on your own research, customer feedback, and industry validation as applicable. You don’t need your team to approve the details as long as they’re good with the high-level approach. What you do need is a set of strong success KPIs. Extra brownie points if you can bake in experimentation to figure out which bits of the feature resonate with customers and which don’t. Your success KPIs should determine how to evolve the feature, not your team, your sister teams, or your boss. In fact, the correct place to lean on your team’s feedback is to discuss the KPIs and evolve both the feature and the KPIs that measure success AFTER it has been released.
Bosses, sorry to say that you’re some of the worst offenders. I’ve encountered countless scenarios in my career where executives try to put their thumb on the product roadmap or feature set because of their “gut” instinct. I’m sure most of your instincts are on point, but in the grand scheme of things, I recommend you let your team leaders make those decisions and optimize for speed rather than satisfying your ego. The only exception here is a founder who is trying to change the trajectory of the company.
In short, optimize for rolling the dice, measuring the results, and iterating, versus debating forever about how many sides the dice should have or its color.
What should it look like - Put a bunch of random people into a UX review and instantly they all become designers with a point of view on what the user experience should look like, including having opinions on very low-level details like what the color palette should be! I absolutely recommend against UX reviews that have non-designers in them. The only exception should be the product manager who is working closely with the designer to design the overall experience. And in the end, if the designer and the product manager agree on the overall user experience, there’s no need to include all other feedback. Everyone gets a voice, but not everyone gets a vote.
However, just like you can use success KPIs like engagement, stickiness, and activation to measure how well a feature is doing, you can use usability metrics like task success, time on task, number of errors, ease of use, and NPS scores to figure out how well the user experience is working out for the end user. Additionally, UX flaws will also affect feature-level success metrics like engagement and activation, so you can look at those as well to figure out how to evolve the user experience. Just like in the previous section, optimize for speed and measurement versus democracy and social cohesion. The user experiences of modern web and mobile applications are fairly easy to change, so don’t overthink what the initial experiences should look like. Just get it out there, measure, and iterate. And again, bosses, please don’t put your thumb on the UX design. Assuming you have a competent team, focus on giving them thoughtful feedback and let them decide what they want to do with it. One of the worst UX reviews I’ve ever been a part of was when they invited the CEO to it. They were hoping to show off their design, but instead ended up needing to rework many trivial parts of the user experience, which in the end didn’t amount to much.
System Design - Senior engineers enjoy organizing design reviews. Who doesn’t want to feel like a king (or queen), guiding their loyal subjects on how to live? Design reviews are beneficial, as long as they aren’t a gate. Many companies treat them as a gate, where the team proposing a new design MUST get approval from the design committee, typically made up of senior, staff, and principal engineers. While it’s extremely valuable to get feedback from the braintrust of your engineering organization, I have concerns about those meetings becoming a gate.
The right approach is to require all major design changes to go through a review, but allow the presenting team to decide whether to accept any or all of the feedback from the committee. Ultimately, the presenting team will have to live with the outcome of their decision, so it doesn’t make sense for them to oppose and commit to a decision that’s forced upon them by an ivory tower committee that won’t be present during a production incident. One exception is if your design not only impacts your systems but also affects systems owned by another team. In those cases, building consensus and alignment is necessary, and if that isn’t happening, the leaders of those organizations need to meet and agree on a way forward.
How to launch it - This is more of an issue with brand new, zero-to-one product/feature launches than incremental updates to existing features, but generally speaking, the quicksand teams fall into right before they’re about to launch something is the conundrum of, “Is it good enough?” Other variations of that question could be, “Did we fix all the bugs?” or “How can we be SURE that this is going to work?” and so on. Bottom line: even the best laid plans can implode after launch and, conversely, the worst laid plans can sometimes land really well with customers. There are numerous stories of side projects or features becoming popular enough that teams abandoned their main ideas and pursued the side idea instead. Slack is a great example. The team was originally working on an online game when they built Slack as an internal communication tool because what was available in the market didn’t work for them. And Slack became so popular with the team that Stewart decided to kill the online game idea and just focus on Slack full-time, and the rest is history. The bottom line is, you really don’t know exactly how a product or feature will do in the wild until you release that damn thing. No amount of testing, user research, or prayers can ever give you 100% confidence that it will work exactly how you predicted it would. My recommendation to product development teams is to always roll the dice as long as you can control the blast radius in case the dice roll out of your control and into a ditch. Meaning:
Define and instrument metrics (customer and system) that will immediately tell you how the product is doing post-launch
Release it to a small cohort of customers first. If your metrics are holding steady, expand the pool of customers who have access to it
A/B test wherever you can
There’s no rush to GA any feature. Slap a beta label on it and keep it there until you’ve seen enough customer usage in the wild to determine if the feature is working for your customers or not. Some teams rush to GA things because they committed something to leadership. Trust me, your bosses aren’t going to be upset that you’re not GAing it. They’ll be upset if you GA it and the feature gets punched in the face by your customers
Don’t nitpick user experience warts. If the product/feature is solving a real pain point for customers, they’ll find a way to love it. Case in point: just download any banking app
Don’t overthink GTM activities. Assuming you know your customers well, just put out a plan that you think is good and launch with it. If the feature is valuable, customers will find ways to find it and use it
The only thing you SHOULD be somewhat sure about before launching a new product or feature is its pricing. Even with a beta label, it’s very hard to change pricing on customers without undergoing some (or a lot of) churn. So if you want to spend extra upfront time on anything, spend it on nailing your pricing
Before wrapping up, a quick note about escalations. One of the things teams and leaders struggle with is escalating quickly. Meaning, if there’s a disagreement, pushing the escalation upward to someone who can break a tie. Either consciously or subconsciously, people feel it’s poor form to escalate. They think it’s like crying wolf. In my experience, it’s the opposite. Senior leaders and executives desperately want to help. They want to speed things along. In the context of making decisions, never feel like you’re being a snitch by escalating things to your boss quickly. Escalate quickly and pull others in who can make the decision and help move things along.
The irony of optimizing for decision velocity is that it feels riskier in the moment but is actually far less risky over time. Yes, you’ll make some wrong calls. But you’ll learn from them quickly, course-correct, and still ship faster than teams that spent months trying to make the “perfect” decision. Speed compounds, and so does the learning that comes with it.
And that is it! Until next time!