Slow is Smooth and Smooth is Fast

How moving slow as a Product Manager will help you execute at a higher level

Product management is stressful and hectic. When someone asks me to describe a typical day as a Product Manager, I often think of this meme.

2013 webcomic by KC Green

Since the PM role sits in-between business goals, technology constraints and stakeholder demands, there is a constant stream of competing requirements. Therefore, at any given moment, your day can get turned upside down by a critical production bug, a new request from the c-suite or a challenging interaction with a customer. When this happens, it’s natural to instantly want to respond to an issue in an attempt to fix it. Especially if it’s a request from your manager or a prominent executive.

Slow is smooth and smooth is fast is a saying made popular by the Navy Seals. While this sounds counterintuitive, the ability to go slow and plan, improves decision making speeds and maximizes execution. When the room is on fire around you like the dog in the meme, the last thing you may want to do is move slowly. Embracing slow is smooth and smooth is fast has helped me handle stress and better prioritize the endless PM trade-off decisions.

Recently, we received a request to add a new consent form to our signing package from the CEO himself. A request from the CEO requires immediate action, right? The initial urge was to start forming a solution for the problem to get it done asap, “Oh, this is easy. All I have to do is add another document in our signing package and add a signature line”. After some digging, we discovered we needed to capture more attributes than just a signature like email, date and IP address. Some more research found some new requirements like the ability to have the borrower accept or decline the consent form. Finally, proper investigation uncovered that we already had this form and we were collecting the necessary information but we weren’t sending it to the database.

In this scenario, the initial gut reaction to “just add a new form” would have cost the team more time and effort in the long run. We would have created and designed a new form, mapped new data fields, collected additional information and then sent it all to the database. However, moving slow and doing the proper research upfront saved the team hours of wasted work since we had all the information already. Slow is smooth and smooth is fast enabled us to execute at high speeds to satisfy the CEO’s request with minimal effort. Now we have more time and energy to work on other impactful requests.

The next time you get an urgent product request, try and practice moving slowly first by:

  • Fighting the urge to immediately offer a solution. Instead, tell the stakeholder that you are going to do proper research to find the best way to solve their problem.

  • Realizing doing nothing is OK. Not every request requires a response. Some demands resolve themselves over time while others just aren’t that important. Moving slowly will help you evaluate these decisions.

  • Asking why. Getting to the root cause of why the stakeholder is requesting something is critical for your ability to take appropriate action. Don’t settle for the first explanation.

Learning how to move slow in a hectic environment has transformed my product decision making skills. Staying calm has improved my confidence levels and has helped me think more clearly in ambiguous situations. Do you find yourselves moving too fast at work?

Don’t worry about sounding professional. Sound like you. There are over 1.5 billion websites out there, but your story is what’s going to separate this one from the rest. If you read the words back and don’t hear your own voice in your head, that’s a good sign you still have more work to do.

Be clear, be confident and don’t overthink it. The beauty of your story is that it’s going to continue to evolve and your site can evolve with it. Your goal should be to make it feel right for right now. Later will take care of itself. It always does.

Read more articles like this.

Previous
Previous

Why do product managers make bad internal tools?

Next
Next

Traditional vs. Gherkin User Stories