Steve Croy

Stop gathering requirements. Anyone can make a list of features. Anyone can write down what people say they want. That’s not product discovery. Product discovery is about going deeper. It’s about understanding your customer’s pain points. Feeling their frustration. Seeing the gaps in their work. It takes time, patience, and empathy. It takes stepping away from the solution and sitting with the problem. Great product leaders don’t rush this process. They fall in love with their customer’s problems first. Because when you truly understand the problem, the solution will rapidly emerge. Are you giving yourself the time and space to discover your customers’ problems? #Discovery #Product #Agile

29

6 Comments

I've noticed a recurring theme when speaking with many product managers: a sense of shame and disappointment. You've dedicated so much—time, money, and energy—to your career. You've pursued certifications and technical training, hoping for that big break. But instead, you feel stuck, overshadowed by your peers' success. You've taken the leaps, committed wholeheartedly, and executed with precision, yet the return on investment seems just out of reach. It's a frustrating puzzle. Your colleagues and engineering teams constantly remind you of your exceptional worth and input. So, why does success seem to elude you? Let me share a candid insight with you—it all comes down to one pivotal element: embracing your authentic voice and power. Many fall into the trap of adhering too rigidly to the prescribed path to success, doubling down on conventional wisdom, frameworks, and methodologies. In the process, they lose sight of their unique voice, their story, and the very essence they yearn to be recognized for. In the quest to conform—to fit into the mold of 'best practices,' to accumulate technical know-how, AI expertise, and ML prowess—they inadvertently relinquish their distinctiveness and power. This realization struck me: the differentiation we seek, the edge we crave, isn't nestled in the technicalities. No wonder there's a lingering sense of disillusionment—the journey toward technical mastery inadvertently distances us from the core of what truly sets us apart as leaders in product management. Here's a thought to ponder: standing out doesn't come from just certifications. It's about harnessing and highlighting the skills you possess, not just in executing tasks but in articulating the value of your contributions, both within and beyond organizational boundaries. By diving deep into technical training, we risk becoming just another 'me too' product manager rather than elevating ourselves through our unique strengths and perspectives. The real competitive advantage lies not in technical acumen but in cultivating, showcasing, and advocating for your unique blend of product management skills tailored to the environments and challenges you're most passionate about conquering. Comment "toolkit," and I'll share my core product management toolkit, which will help you more than most certificates and technical training.

23

8 Comments

In product demos you need to stop saying "it depends". When someone asks if your product can do something, ask why it matters. 1. "Can you give me an example use case where that would be required? 2. "How do you achieve that today?" 3. "Can you walk me through the steps you're looking to take where that would be needed? 4. "How important is that capability to you at this time?" 5. "Would you be open to a different approach?" Saying that it depends on circumstances is a closed-off response and leaves your prospect wondering whether or not they can actually do what they need. Instead, asking one of the above questions enables you to advance the discovery process, and build rapport and trust. I often wonder how much money I'd have now if have an "it depends" swear jar on my desk.

49

12 Comments

Thought experiment... delete your roadmap. Stop everything. Now play things out... For the past year or so I have experimented with an activity. I ask teams to imagine that they stop "shipping". Nothing new. No improving existing features. They keep their jobs, and fix major production issues, but otherwise stay idle. When possible, I ask them to refer to some sort of business dashboard or statement. How do these numbers change? They imagine industry press, coffee machine conversations, customer feedback, and board meetings. What happens with the passing months? Could X possibly go unchanged? Would you be surprised if Y doubled? The responses are very interesting. It feels unnatural to imagine doing nothing (even if doing nothing may be the best decision). We're wired to keep ourselves busy and talk ourselves into our grand plans. In some businesses, the impacts of doing nothing are felt quickly. In others, teams find they can go a year or more without real "damage". A competitor gains ground. Cost of acquisition increases. Team members leave for a competitor (or to start their own businesses). It hits home that successful products are a slow burn, the result of many decisions over time. To tackle the exercise, some teams review the past year. How did that work contribute to where the business is today? For new product launches, add-ons, packages, etc. it is easy to say "if we hadn't done this, then X wouldn't have happened." We gravitate to obvious connections, but that is a trap of sorts. The purpose of this exercise is to surface assumptions, and to focus the team on the Opportunity. Yes, it is "not realistic". It takes some practice, but more than practice it takes freedom and safety. Freedom to explore a possible future without judgement. "Non-business" types (if there is such a thing) need to feel free to explore the problem-space. Give it a try! With a big cross-functional group. Folks with more familiarity with “the numbers” should be prepared to teach and guide. Folks with more familiarity with the long-term, slow-burn issues (market share, inertia, product phases, ecosystems, etc.) should do the same.

355

32 Comments

Product roadmaps shouldn't be treated like a to-do list. They're living documents that tell the story of your product's evolution and adapt with customer needs. 🌱 I learned this lesson the hard way. Early in my career, like many founders and product folks, I viewed roadmaps as rigid plans to execute against - plugging items into project management tools and checking off boxes each quarter. While this felt satisfying, this output-based approach missed the point entirely. 😬 Here’s the roadmap philosophy I live by today: The art of roadmapping isn't about the output - it's about the process. 🏗️ Or, as Winston Churchill offers, "Plans are of little importance, but planning is essential." When viewed through this lens, startup roadmaps are a tool that helps you: 🗣️ Articulate your vision clearly to different stakeholders 🎯 Prioritize work that moves you toward that vision 🛞 Adjust quickly based on customer feedback 🤝 Unite teams around shared goals For early-stage companies, I’ve found the best way to do this is to create and maintain three versions of the roadmap, each for a distinct audience: 1️⃣ Annual roadmaps for investors: Focus on major milestones and market opportunities 6-12 months out. This shows your strategic thinking and excites investors about long-term potential. 2️⃣ Quarterly roadmaps for customers: Share concrete value coming in the next 3-4 months. This builds excitement while maintaining flexibility to pivot based on feedback. 3️⃣ Internal roadmaps for teams - Break down the work into specific problems and experiments to tackle this quarter. This connects daily tasks to bigger goals (which we manage in Linear). For each version, the key is focusing on the problems you're solving rather than features you're building. This shift in mindset leads to better products, more engaged customers, and teams that understand the "why" behind their work. ❤️ The best roadmaps aren't about checking off feature boxes - they're about delivering value by aligning your team, customers, and investors around a shared vision for the future. If you’d like to dive deeper into my thoughts around this topic, I’ve written up a post on creating your first roadmaps as a startup founder on the Clarify blog. I’ll drop the link in the comments 👇

71

13 Comments

Must-watch conversation between Lenny Rachitsky and Melissa Perri, where they dive deep into product management strategies and, of course, take a few well-aimed jabs at SAFe. If you've ever felt that SAFe is more about bureaucracy than agility, this one's for you.

13

1 Comment

Human's are really bad at self reporting. Asking someone what was difficult for them and why will return suspect data. When you watch someone attempt to do something, like we do when we perform usability testing, you get valid feedback and actionable information.

20

4 Comments

Product is fun, complex, messy, and there are no shortcuts. Once you accept that—and embrace it—amazing things happen to your career. Cat Hicks, PhD puts this better than anyone: "Doing research with developer teams, something that really strikes me is how much people look for ways to make complex problems easy rather than make it easy to work on complex problems What I mean is, sometimes it's really useful to admit we just are trying to accomplish tough things. Asking how we can support our teams who NEED the time and space to work through that, it's often a much more tractable lever than trying to change the inherent nature of the work I think it behooves me to say as a psychologist here that I think people are actually really excellent at working on complex problems! It's one of the reasons research with developers is so great. Overall devs love to learn, love to be curious, love to innovate. It is core stuff. What would it look like if we could ask, "how do I make this the absolute best environment for complex problem-solving" instead of "how do I take away all these annoying hard problems." The stuff we want to accomplish in the world is hard. But can be joyful to accomplish."

250

14 Comments

Scaling a product organization isn’t just about adding more people. It’s about keeping everyone aligned and moving in the right direction. When you’re leading 15+ product managers and 100+ engineers, the quick chats and informal updates that used to work no longer cut it. Suddenly, visibility into priorities, progress, and blockers feels scattered, and staying on top of it all becomes overwhelming. This is where product operations step in (and why I'm so passionate about it!). Product Ops isn’t just about processes, they’re about enabling clarity. With the right systems in place, you can track progress against OKRs, identify risks early, and focus your energy on high-impact decisions instead of chasing down updates. ➡️ Scaling doesn’t have to mean losing control. By leveraging product operations, you can create the structure needed to scale without sacrificing visibility or alignment. How do you keep your team focused and aligned as it grows? Let’s discuss strategies in the comments!

77

8 Comments

I love this more nuanced approach from David Morris for determining what product ideas should get on the roadmap. The technique I use and coach most often is a bit simpler. It's "doable" vs "desirable". David's Viable + Feasible is a nice way to split out the two aspects of my "doable". I define great product management is a simultaneous exploration of the doable vs desirable space to find the optimal tradeoff between the two. So, the exercise I facilitate has people put post-its up on the wall on a two-dimensional graph where the x-axis is how "doable" the idea is. The y-axis is how desirable it is. The "best" ideas end up closest to the upper-right corner. I then draw two squiggly lines on the chart, generally meandering, going from upper-left to lower-right. The first line is quite close to the upper-right corner, meaning that only a small fraction of the ideas will be above and to the right of it. Anything above and to the right of it is considered a commitment for the roadmap timeframe under consideration. The second line is close to the first and catches the stretch goals for the roadmap timeframe. I'd love to host such an exercise for anyone who's interested, using David's nuanced version of "doable". Thoughts? Owen Farrell, Tony Reinert, and Tony Mantoan, you've seen me host these exercises many times. How well do you think this alteration to my exercise would work? https://lnkd.in/eaTGz6ep

6

4 Comments

Your most important outcomes as a PM will not be driven by you. At least, not entirely. For outcomes that truly matter to the business (revenue, retention, CAC...), your work needs to work in symphony with all the other departments to have impact. This was my key takeaway from Nick Boccone's Outputs vs. Outcomes workshop at #ProductTO last night. Outcomes are events. They can happen without your involvement. Outputs are actions you and your team take. Sometimes, they inform outcomes — but never on their own. It led me to revisit this recent podcast from Leah Tharin featuring Kyle Poyar; this might sound like "just GTM stuff" that doesn't impact you... but until you realize how the business engine works, and the role each department plays in that engine, you're very limited in the outcomes you can drive as a Product Manager. https://lnkd.in/gg3s28-R #growth #productmanagement

15

4 Comments

Software folks: Product people are not the enemy. The often adversarial relationship between Engineering and Product (or really any two departments) has been a continual source of frustration throughout my career. The amount of time I’ve spent reminding people with different roles that they work for the same company borders on the absurd. I understand why this happens, but it’s still troubling. For example, I recently listened to an engineering leadership podcast where the host asked the guest about an engineering manager negotiating priorities with a business leader. Negotiation is generally a good thing. Groups make better decisions when they take multiple perspectives into account. However, the host talked about “winning” and “losing” the debate. At the point where you frame a decision-making process as an argument, you have already lost. The goal in a process like this is to make the best decision possible, not to win or lose. One of my litmus tests for a healthy product development team has long been, “Do the engineers consider the Product Manager part of the team? Are they willing to go to bat for the PM?” When we remember our shared mission and all pull together, we can do amazing things.

31

39 Comments

Reforge published my artifact 🎉 How to use a driver tree to assess a business outcome for #ProductManagers. The artifact library (free to use!) provides real examples to help PMs develop their craft. The driver tree I've shared is fully functional. Open the spreadsheet and give it a try 👉 https://lnkd.in/gMPxDffc

85

4 Comments

Technical founders can sometimes get so enamored with the product they are building that they really don’t understand why customers actually buy their product. I’ll take it one step further… Sometimes your product might be only 25% of why a customer buys, the other 75% is stuff you might not even realize until you take a closer look at each specific buyer. - Some buyers value the quality and responsiveess of your support above product feature maturity or feature parity with competitors. - Others use your product and also desire a partner they can work with, for example to teach others and conduct educational workshops. - Still others have specific KPIs and they are buying your product as a means to an end. They see the customer success team as partners who can work with them weekly to help meet and exceed their objectives (cloud cost optimization, increasing the satisfaction of the end users they support). Advice to the founders in my network, take the time to try understand why your customers buy. - It might have less to do with your feature roadmap and more to do with how you show up when they need you and how you help them win. - Your product offering also gets better faster when you understand all the manual things your sales, support, and customer success team do to get the sale and make customers happy. - Talk to more customers to understand why they first bought and why they continue to be paying customers. Understanding why customers really buy makes it so much easier to prioritize the product roadmap and find ways to improve the sales cycle and customer retention. What do you think? Have you experienced the disconnect that can sometimes occur between founders and customer facing leaders? Would love to hear your experiences and advice for others in the comments.

6

1 Comment

Have you heard the news? Our team at Pendo.io is excited to be offering our Product-Led Certification Course for free! The course covers the fundamentals of being product-led and provides actionable product-led strategies to drive growth for your organization. Register now while it's still free to take the course and earn your certification! ⬇️ #ProductManagement #ProductInnovation #BusinessLeaders #Product

5

I see a lot of posts about how you SHOULD be managing your product. I see a lot of opinions, often diametrically opposing one another, about how PMing should be accomplished. I learn a lot from these posts about how other people are succeeding or where they’ve failed. Ultimately what I’ve found is that, like anything else, Product Management has a lot of potential routes to success and there’s no single way to “get to greatness”. That said, there is one tell tale sign that you’ve reached great. Your product grows and evolves with regular user feedback, a strong NPS, and your strategy is driven by your product in line with your organization’s goals. If this is happening, you’re in good shape. Keep those metrics in the green and you’re doing great!

5

If you want your PS team to be more than just executors, invest in their ability to think like business owners—not just technical experts. Here’s why: The most successful PS teams are more than project executors. They’re strategic partners who can translate client needs into business value—AND understand how that value ties back to your company’s bottom line. But too many leaders are missing this crucial investment. They hire great technical talent, yet fail to equip them with the financial and commercial skills needed to truly scale. Here’s what happens when you level up your team’s business acumen: 𝗕𝗲𝘁𝘁𝗲𝗿 𝗱𝗲𝗰𝗶𝘀𝗶𝗼𝗻-𝗺𝗮𝗸𝗶𝗻𝗴. When your team understands the financial impact of scope creep, poor utilization, or inefficient processes, they make smarter decisions. 𝗦𝘁𝗿𝗼𝗻𝗴𝗲𝗿 𝗰𝗹𝗶𝗲𝗻𝘁 𝗿𝗲𝗹𝗮𝘁𝗶𝗼𝗻𝘀𝗵𝗶𝗽𝘀. A team that “gets” business speaks the client’s language, helping them articulate the ROI of your services. 𝗥𝗲𝘃𝗲𝗻𝘂𝗲 𝗴𝗿𝗼𝘄𝘁𝗵. Teams that think beyond deliverables create upsell opportunities, identify cost-saving initiatives, and expand engagements naturally. 𝗘𝗺𝗽𝗼𝘄𝗲𝗿𝗲𝗱 𝘁𝗲𝗮𝗺𝘀. When your team understands how their day-to-day work affects P&L, they start thinking like owners—not employees. How do you start building business acumen in your team? 👉 Teach them to read a P&L. A little financial literacy goes a long way in shaping better project leaders. 👉 Involve them in pricing and forecasting. Let them see the “why” behind decisions, not just the “what.” 👉 Pair junior team members with mentors who can help them understand the commercial side of projects. The result? A team that thinks strategically, executes flawlessly, and drives growth for both your clients and your company. What’s one way you’re helping your team improve their business acumen? Share your experience below!

9

4 Comments