post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Product Management

Sunday Rewind: Whose job is it anyway? The rise of Product Ops and why it deserves to be an independent function

Guest Post

Creating metrics that matter

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

How much are product managers getting paid in 2024?

Leading product ops at Delivery Hero with Koen Dubelaar

Connecting fans to creators at Spotify (Dariusz Dziuk, Product Lead, Spotify)

“You’re not as competent as you think” 5 lessons from Ken Chin on navigating a product career (CPO, Spark Networks)

Everything wrong with the product management job market. And how to fix it

Shabnum is a Senior Product Manager at Honey, an LA based startup (recently acquired by PayPal) that helps users save money when shopping online. Shabnum was briefly the Virality Products Lead on the product-growth team at Honey, and now leads Honey's budding fintech product. Before Honey, Shabnum was a Product Manager at Capco, a digital consultancy for financial services. In her time at Capco in both New York and London, she led the end to end development and launch of mobile and web banking applications and APIs. Shabnum's product experience has spanned a variety of clients in both retail and private banking as well as internally at Capco. In her spare time, she enjoys dancing and theatre.

Product Manager

Shabnum Gulati

<p>Failing is an eventuality in software development. Not only do we fail, we are encouraged to fail <strong>iteratively</strong>. Let’s do it over and over again!</p>
<p>And yet, the job of the product manager comes with a level of accountability and scrutiny that is unique. Product managers are asked to look after all facets of a product’s development, from conception to launch. From software design to user experience. From consumer needs to integration points. Jobs to be done, design-led thinking, microservices, object orientation, service orientation, user stories, product-market fit, launch strategy, data models, customer segmentation, framework after framework, after framework. A working knowledge of just some of this is enough to make anyone’s head spin, let alone keep it all in check in order to deliver successful products.</p>
<p>After all, a large portion of the tech industry is in business precisely because they know we will fail, and advancements in software development increasingly take the pain out of failure. Cloud computing enables elasticity in anything from load balancing to server use, introducing the ability to take human decision out of scaling. Fears of excess payment have been reduced by pay-as-you-go models. Versioning allows us slowly to phase our approach and test new features. Disaster recovery and failover assure us that we will be kept safe despite colossal accidents.</p>
<p>More and more the technology community likens failing to falling down on a trampoline and jumping right back up. We no longer need to anticipate every customer need, get the journey perfect the first time, or plan for unexpected loads &#8211; Amazon, Microsoft, and Google will forgive us for planning poorly (at a small price of course).</p>
<p>The industry is moving at an unprecedented pace because it’s so easy to get up again after a failure. Deploying and launching is easier than ever before, so we are encouraged to just <em>get to market</em>. <em>Just ship. </em>Often we find ourselves asked to do too many things at once without doing any one thing emphatically well.</p>
<p>Failing has become the norm, imitation too easy, and costs are getting lower every day. Despite all of this good news, the product manager’s job seems to have become more complicated. If imitation is too easy, then proving competitive advantage is difficult. And if costs are becoming negligible, we have so many options that setting boundaries is hard. It’s getting harder to maintain competitive advantage and be sure we’re making the right decisions.</p>
<p>So how can we make the right decisions in a sea of options and competing products? While I’ve always found it difficult fully to get a grasp on what all my options are, I’ve found that the best way to inform my decision-making process is to roll my sleeves up and unpick each option. The daunting task of <em>really</em> understanding how everything works has come in handy when selecting vendors, choosing which features to prioritise, and building products that will scale &#8211; constantly fighting the urge to come up with high-level solutions and roadmaps first. Start from the bottom, block by block. Here are some of the hacks and tools I&#8217;ve found that have made my decision making easier, and which have helped to make my failures a positive learning experience.</p>
<h2>1. Milk the System</h2>
<p>If there are a variety of tools available and switching is easy, find the one that works best for you. This sounds trivial, but take advantage of the free trials and free demos. Get your hands dirty! Play around even as a product manager to understand exactly what set of tools you’re getting. Example: sign up for an AWS, GCP, Heroku account. They’re all free to get started, and you can get a great idea of the suite of products they offer and which scaling options work best for you. And you’re allowed to ask for freebies. Don’t hesitate to ask. If there’s a vendor whose API you’re looking for, be empowered to ask for a test API. The most they’ll say is no.</p>
<p>On one of my projects, my team needed to spin up a static website to publicize our product quickly. We were limited, however, by our client’s governance processes and getting access to their enterprise AWS account. After playing around with AWS myself, I realized we could just as easily host our static website through Dropbox, since the underlying technology is the same. I knew it would scale well &#8211; if only to accomplish the singular goal of redirecting users to our core product. Not only did this solve an immediate short-term problem, it was the simpler, faster approach that let us concentrate on the larger product hypotheses we wanted to test with our customers.</p>
<h2>2. Join Forces</h2>
<p>Really think about whether building it yourself is the answer. In an open source world, the chances are that someone’s already built it. You might think what you’re after is easy enough to build yourself, and that’s your call. But part of your expertise comes from understanding how long and how much it would take to build it yourself and comparing that against the cost of purchasing. It might even be free! Do the research.</p>
<h2>3. Build it Yourself</h2>
<p>This sounds contrary to number two, I know. Sometimes there will be products that do what you need them to do, but not always in the way your team or your product needs them to be done. Try your best to make an accurate assessment of whether your team can build this, because if they can, you’ll have your own proprietary technology completely fit for purpose. And if they can’t, even better. You’ll have learned a variety of lessons about your dataset that you will not have foreseen before. Time constraints and resourcing constraints will dictate whether you can afford to go with number two or number three.</p>
<h2>4. Deploy as Frequently as Possible</h2>
<p>The deployment pipeline often isn’t in the hands of the product manager, but when you can control how often your team ships, do so. Each release will teach you a variety of lessons, specifically about your dependencies and data points. You will not be able to anticipate each edge case and linkage until you’re actually experiencing it. The more you release, the more things will break. <strong>Fix them and move on.</strong> If you haven’t guessed already, that’s the theme of this article! The urgency here isn’t in releasing or shipping fast, the urgency is in learning fast. And a wise someone somewhere once said, “you learn the most from your mistakes”.</p>
<p>As product managers, our jobs are not to prevent or reduce failure, rather to overcome failure after failure while getting the best out of our products and teams. So we should look beyond “getting everything right” the first time, or even the second time.  Failures in themselves are elastic, and the important lesson to be learned from each failure is what each one taught us about our customers’ needs and preferences, our teams’ ways of working, the data we have, and the journeys that will deliver the most value.</p>

4 Product Management Hacks to get the Most out of Failure

Shabnum Gulati

Read more

Comments