post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Artificial intelligence (AI)

How to build AI products that users trust: 3 core focus areas to stay user-centric

Product Operations

Leading product ops at Delivery Hero with Koen Dunbelaar

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! 🎉

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

Mistakes, learnings, and a product person’s relentless journey into leadership

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

My key lessons from creating digital product for the MENA region 

Sharon has been working in the tech industry for over 15 years. She started her path as a Software Developer, where she got exposed to the Product Management role which she found fascinating. 10 years ago Sharon made a career change and got her first role as a Product Manager, and never looked back.

She specializes in building B2B products, especially in early stages, getting them from incubation stage to commercialization.

Sharon Feldstein

<p><em>Product leader <a href="https://www.linkedin.com/in/sharon-feldstein-80066053/" target="_blank" rel="noopener">Sharon Feldstein</a> looks at what it really means to be an agile product team today and how to balance this with product strategy and long-term goals.</em></p>
<hr />
<p>When I started my first job in tech, “agile” was THE thing everybody talked about.</p>
<p>It was perceived as our savior from writing and executing long PRDs (product requirements documents), from waiting for weeks until a new feature was delivered and even longer to validate it, and in general reacting slowly to customer needs.</p>
<p>The agile methodology has evolved over the years. It has formed the basis for many new practices and every organization has shaped it to its needs. It has been adopted so well by organizations, that lately, I get the feeling that we’ve forgotten what problem it was meant to solve.</p>
<p>I had many conversations with the (wonderful) CEOs and VP of sales I worked with who thought that the Product team should be more agile. The Product team was agile, but it was their very different concept of being agile that often caused this friction. For me agile is about delivering value to our customers faster, for them it’s a way to satisfy customers quickly. They may sound similar, but in practice, they lead to different results.</p>
<h3>What does it mean to be agile?</h3>
<p>Being agile means that you accept that you don’t always know what’s the best solution for a problem, even if the problem is well articulated. It means that you always keep your customers in mind while developing a feature and validate that you’re building the right thing again and again during the development process.</p>
<p>This is done by splitting the work into short iterations, so that there’s a deliverable ready for clients at the end of each one. After each iteration, you validate your solution and adjust the plan if needed. It gives product managers the chance to apply learnings quickly without spending time specifying and developing features that might not deliver the greatest value to our users. And users keep seeing progress in the product.</p>
<p>Agile is a pure execution mindset. It doesn’t tell you what to build and how to prioritize, but it forces you to stay focused on your clients and the value they get.</p>
<h3>What does agile have to do with defocusing?</h3>
<p>Because the time to value is now shorter (you can deliver value in a sprint), I see many cases where managers try to push new “small” features to the development cycle regardless of the product strategy. Usually, this is done at the request of a strategic customer, or if it might help close a deal with a new lead. As a whole, it might sound like a good idea, but what we fail to see is that these small features, when accumulated, come with a price:</p>
<ul>
<li>The system might become harder and harder to maintain &#8211; with many different flows to support</li>
<li>The user interface might become complex and less intuitive</li>
<li>The more of those features you work on, the less you promote your product strategy and vision</li>
<li>The value proposition might become less clear, and once you lose sight of it, it’s easier to further stray away</li>
</ul>
<p>I once talked with management at a startup in its early stages about how they saw the role of the VP of Product in their organization. They told me they needed someone who understood that there were many different opportunities out there and that Product needed to be agile and not just say “no” to everything.</p>
<p>To me, this demonstrates that they were trying to deliver different capabilities to different use cases and personas just because they didn’t want to miss an opportunity. And they were doing it without a clear strategy and understanding of where the company should be in the next five years. From a product perspective, such products tend to be hard to maintain and hard to explain. If you were to look at their roadmap you’d just find a list of different features.</p>
<p>Try to imagine working in such a startup &#8211; It’s impossible to prioritize as there’s no focus on a single set of use cases or values to be delivered, no focus on a specific persona. It’s hard to plan for the future, and even harder to delight, as you’ll probably find yourself trying to add basic capabilities to keep all the different users satisfied.</p>
<h3>How to stay balanced?</h3>
<p>So we understand that the real question is not whether we’re “agile” or not, but more about how we balance product strategy with different opportunities.</p>
<p>Just to be clear &#8211; this balance is extremely important. The last thing we want is a yearly roadmap that we execute just because we built it. As in everything we do, we have to constantly validate the plan, and be open to new opportunities (both proactively and reactively).</p>
<p>So, when we are asked to push a new “small” feature we need to ask ourselves:</p>
<ul>
<li>Does that align with the product strategy? Is it getting us closer to where we want to be?</li>
<li>If not, do we want to invest in that direction? Which other clients/ personas can benefit from it?</li>
<li>Will it solve the problem of the customer? Often we find out that the small request that was made was just the tip of the iceberg and to solve the problem you have to invest a lot more time and resources</li>
<li>What is the impact on the product &#8211; will it be harder to maintain? Will it become more complex?</li>
</ul>
<p>For small startups, this thing is even more difficult, as usually when you’ve just started out you don’t know what persona or targeted client would gain the most value from your product. You’re still searching to prove your use cases, and in those cases, you reach many different people from different organizations to better understand which direction you should take.</p>
<p>The most important thing you (with the management team) should do is constantly assess the status and decide on the future steps. For example, if you’re focusing on small or mid-sized businesses, what’s the cost of onboarding a big organization? How would it affect your other clients and your product? If you’re testing several use cases in different clients, be ready to deprecate the use cases that you found that were less valuable to you and that don&#8217;t fully align with your vision or goals.</p>
<p>Once when I was working on a new product line, our sales team managed to bring two new big organizations that showed interest in our product &#8211; each one had a very different way to gain value from it. This was good news, and we immediately started to build the product in a way that would fit both of them. As we moved along, we understood that there was no way we could continue and satisfy both of them &#8211; our team was small and we couldn’t incorporate their needs in a smooth way that made sense. We had several long and difficult conversations where we assessed the market and our capabilities and we eventually decided to keep with just one client. It was a painful thing to do, but it enabled us to focus on the use case that we thought would bring the most value, and once we’d done it everybody’s life improved. Sales knew exactly what they could sell and to whom, the R&amp;D team knew what direction we were taking and was able to plan the system architecture accordingly, and the product team was able to plan better solutions for this use case.</p>
<h3>To conclude</h3>
<p>We have a product strategy and yearly goals for a good reason &#8211; this is where we want our product to evolve, and where we need to put our focus. When you confuse the purpose of the agile methodology and use it as a means to quickly satisfy clients, you may stray away from your product strategy and find that you don’t build a product that gives value to your clients. We have to be aware of this, and constantly check that we progress in the desired direction that leads us to the best outcome.</p>
<h3>Access more great content on Mind the Product!</h3>
<ul>
<li><a href="https://www.mindtheproduct.com/escaping-build-trap-melissa-perri/" target="_blank" rel="noopener">Escaping the build trap by Melissa Perri</a></li>
<li><a href="https://www.mindtheproduct.com/how-to-conduct-productive-sprint-planning-meetings-for-product-managers/" target="_blank" rel="noopener">How to conduct productive sprint planning meetings for product managers</a></li>
<li><a href="https://www.mindtheproduct.com/product-development-strategy-setup-your-product-for-success/" target="_blank" rel="noopener">Product development strategy: set up your product for success</a></li>
</ul>

Being agile does not mean you can defocus

Sharon Feldstein

Read more

Comments