This site uses cookies to improve your experience. To help us insure we adhere to various privacy regulations, please select your country/region of residence. If you do not select a country, we will assume you are from the United States. Select your Cookie Settings or view our Privacy Policy and Terms of Use.
Cookie Settings
Cookies and similar technologies are used on this website for proper function of the website, for tracking performance analytics and for marketing purposes. We and some of our third-party providers may use cookie data for various purposes. Please review the cookie settings below and choose your preference.
Used for the proper function of the website
Used for monitoring website traffic and interactions
Cookie Settings
Cookies and similar technologies are used on this website for proper function of the website, for tracking performance analytics and for marketing purposes. We and some of our third-party providers may use cookie data for various purposes. Please review the cookie settings below and choose your preference.
Strictly Necessary: Used for the proper function of the website
Performance/Analytics: Used for monitoring website traffic and interactions
Guest Post by: Marvin Mathew (Mentee, Session 11, The Product Mentor) [Paired with Mentor, Jordan Bergtraum]. Ruthless prioritization translates to product teams spending time building the right thing at the right time. Each feedbackloop has a minimum of four stages. The feedbackloop process is.
Think of Net Promoter Score (NPS) software as a tool to measure your customers’ feelings about your product, and categorize them based on their level of loyalty (promoters, neutrals, and detractors). The great advantage of these tools is that they streamline the creation, distribution, and analysis of NPS surveys.
Strategy and ProductFeedbackLoops. Everyone agrees they want innovation: Which products and services the organization offers. What features the product offers, or the problems the product solves. The product roadmap). These problems and questions are all about delays in the system's feedbackloops.
I get asked all the time, “How much time should we spend in discovery ?”. First, it assumes you do discovery first and then delivery second, which is not true. You need to do enough discovery to mitigate unacceptable risk. Now as a discovery coach , I would ask, “How could you have learned about feature B earlier in the process?”
Speaker: Johanna Rothman, Management Consultant, Rothman Consulting Group
Many of us are accustomed to planning for either discovery or delivery. We know how to plan for where we want to be for a product (delivery). And, we know how to plan to discover a market (discovery). Instead of planning for either discovery or delivery, we can use experiments—for all our work.
Here, I assume you want multiple releases for your product. That means you will make different product-based decisions at different times. Consider the Continuum of FeedbackLoops and Decisions. Product owners might want to change the roadmap as often as every 1-10 days, but I don't see that often.
This part is about shortening feedbackloops. However, they now had a production support problem that they needed to fix. They had one piece of feedback: the checkin broke “unrelated” code. It was time to see their feedbackloops. See Your FeedbackLoops. Neither did the team.
” (The team feedbackloop is the inside of the onion for how agile the organization can be. See Multiple Short FeedbackLoops Support Innovation.). The longer the work takes, the more pressure managers exert on the team and the product leader. Teams and product leaders might exert pressure on themselves, too.
I started this series discussing the issue of the various product-based roles in an agile organization. I suggested a product value team because one person becomes a bottleneck. One person is unlikely to shepherd the strategy and the tactics for a product. Can Your Customer Be Your Product Owner? You don't want to.
In Costs of an Agile Approach for Hardware Products , I suggested that an iteration-based approach for hardware was too expensive. Most of the hardware teams I've worked with (inside an organization and as a consultant) have fewer people. Those people work independently until they need to verify the product as a whole, works.
Is it possible to balance the product innovation and feedback we need, with the commitment our management wants? When does it make sense to ask for more feedback instead? How about when it does make sense to create small or larger estimates for the product? Let's start with the need for very fast productfeedback.
I started this series with the question: If we have teams for all other aspects of an agile approach, why wouldn't we want the product owner to also work as part of a team? Could a team reduce the feedbackloop durations? the PRD (Product Requirements Document) to the team. That's why I suggested the product value team.
In that case, you have a low need for product innovation. Your planning feedbackloops can be longer. We need short feedbackloops in the project/program to see where we are and make small adjustments. Low Need for Product Innovation and Change. I have not worked on many of these products over my career.
Many of my clients are trying to use short feedbackloops in agile approaches. High Need for Product Innovation and Change. The more need for product innovation and change, the shorter the feedbackloops need to be. When the product requires much innovation and change, management doesn't need estimates.
I finally had the transforming idea about how to position the talk: Roadmapping and product planning are about feedbackloops. The shorter the feedbackloop, the faster and more often we can learn. See the post about Double-Loop Learning.) What do customers want and what do they use in the product?
Chasing the next big product win in banking or fintech? According to Quanti research , by the end of 2024, 3.6 Dont Just DigitizeRevolutionize EPAM research (2020) shows 63% of people choose their primary bank based on trust. That means constantly testing new features, listening to feedback and improving the user experience.
Minimum Viable Products: Why You Should Test Before Investing In Ideas Let’s analyze the advantages of MVP-based software development. Boston Consulting Group estimates that 70% of digital business transformation projects fail. When the product met users’ expectations, the entrepreneur continued to develop its functionality.
Strategy and ProductFeedbackLoops About 20 years ago, I taught a project management workshop to IT people. Their products and services did not ship outside the building—their products and services enabled the organization to make money. Show them your feedbackloops and your cycle time.
However, the more often we deliver in short feedbackloops, the more often we can make strategic decisions. Finishing a story creates a new decision point, for both the product and the corporate strategy. The product owner asks the team to finish 5 stories in this iteration. Here's an example. You can change.
Moderate Need for Product Innovation and Change. When the team can plan—and not need to change its plans—for a couple of weeks at a time, the product has a moderate need for innovation and change. Then, the people who manage the product strategy, the product manager/product value team change what the team does next.
Strategy and ProductFeedbackLoops Many of my middle-management and senior leadership clients want certainty about future work. However, I don't do long consulting contracts—by design. But most of my business focuses on coaching, workshops, or consulting. The code and tests are relatively easy to change.
Strategy and ProductFeedbackLoops. We change the feedbackloops. Instead of teams being responsible for delivering product, the managers are responsible for explaining when the managers want to decide. That's the point of all those feedbackloops in the image above.). Or finish a project.)
Do you need feedbackloops so you can: Cancel the project at any time (to manage schedule and cost risks. Maybe you want to use this project as a way to integrate a team into a new product or a new domain. Maybe you want to use this project as a way to integrate a team into a new product or a new domain.
Your product mostly works. If you only have one tester, the team collaborates to test when that one tester is busy. Shorten FeedbackLoops. Next, I suggested that the team find ways to shorten their feedbackloops , in Part 2. I suggested that first, you see your feedbackloops. (I
How product managers can use the Modified Agile for Hardware Development Framework. Many teams have tried adopting Scrum for developing hardware products, not always successfully. Dorian has a deep background in product development, starting in engineering and then moving to business leadership roles.?
When I saw the McKinsey report on “developer productivity,” I shuddered. Second, there's no way to measure such a thing as developer productivity, despite what McKinsey says. Then I read Lorin Hochstein's brilliant assessment in On productivity metrics and management consultants. That makes so much sense.
” It depends on how your lifecycle manages feedbackloops and learning, how collaborative the team is, and how much WIP the team has. Each Lifecycle Manages FeedbackLoops Differently Brooks wrote the original version of The Mythical Man-Month in 1975, based on the 1960s IBM 360 project. That's why there's feedback.
Matt Walton was one of the founders of FutureLearn, where he scaled the product team and organisation from nothing to the significant player in online education that it is today. Along the way, he learned a lot about continuous improvement of both the product and the processes for building it – including the use of [.].
The managers need to “deliver” more projects, products, and features. The problem is that the feedbackloops are too long because the WIP (Work in Progress) is too high. Managers pressure both the teams for faster blue feedbackloops, and pressure the product people for faster red feedbackloops.
Product strategy, to define the value the products offer to the product's users/customers. In addition, you might need these product strategies too: Product architecture, to shepherd the technical value of a product. Test architecture, to shepherd the testing tactics. Your ideal users.).
What does it mean for us as product managers? We all use AI or machine learning (ML)-driven products almost every day, and the number of these products will be growing exponentially over the next couple of years. What does it mean for us as product managers? Lesson 1: Understand the Problem You’re Trying to Solve with ML.
Discovery requires different skills than delivery. Discovery requires short experiments where we can learn something, maybe every day. I think about the various risks for discovery and delivery. You might need to manage your delivery risks before you can manage to free time for the discovery risks. Write them down.
Doing one of my favorite things—presenting at Mind the Product. Over the past six years, I’ve developed and honed my Continuous Discovery Habits curriculum by reading and writing about the best research on problem-solving , decision-making , and critical thinking. I run a 12-week coaching program for product trios (i.e.
Designers often find themselves juggling numerous tools, files, and feedbackloops across different platforms. Key Stakeholders : List the people involved in the project so everyone knows who to consult or update. Research & Insights In this section, document the research findings that influence your design.
And does it work with the product-led growth model? That’s just a couple of questions I asked Krzysztof Szyszkiewicz and Jakub Jukowski of Valueships , a leading pricing optimization consultancy. A robust customer success strategy enables customers to get the most out of the product. What is value-based growth?
Turning Strategy Into Outcomes: Influencing Stakeholders To Achieve Alignment By Erica Wass At a Glance This blog outlines how successful product strategy depends on aligning cross-functional stakeholders, not just building a strong plan. In product management, strategy alone isn’t enough.
Who is responsible for user research at your SaaS? If it’s the latter, your organization may benefit from democratizing research. TL;DR By democratizing research, you make it more accessible and inclusive across your organization. Research democratization empowers staff at every level to make data-driven decisions.
Too many teams have overloaded Product Owners. I first discussed the various roles we often need to define and refine the product as we proceed. That was in Product Roles, Part 1: Product Managers, Product Owners, Business Analysts. That's in Product Roles, Part 3: Product or Feature Teams.
I'll wrap this series up with what you can do if your managers love predicting instead of using feedbackloops. That's why we have projects—to work on this product for now, until we've delivered something. See Projects, Products, and the Project Portfolio: Part 1, Organize the Work to see what I mean about projects.
A couple of weeks ago myself and some of my team sat down to talk about how we could attract some of the best people around to join our Product team. If you’re a product person, then you’re one of us, we understand you. Two of our co-founders (now our CEO and CSO) were Designers and ran a UX Consultancy before Intercom.
It is important that these friendly connections represent the target persona market you have outlined, as otherwise, the feedbackloop is likely to be weak. Meet your target users and get feedback. Iterate the product based on feedback. Are they keen to test it out? How do they describe the category?
That's because agile teams learn together as they create the product. There's an interesting reinforcing feedbackloop here: The team learns by working together. The only thing external people can see is the duration of the team's feedbackloops. Ability to ask for help (which might be related to feedback).
You may have noticed we’ve taken a break from Intercom on Product over the past few months – we didn’t feel it was an appropriate conversation to continue in the midst of the tragic events unfolding around the world. This month’s episode looks at the contentious notion of “product judgment.”
” Or, someone gets pulled off to work on production support issues and is no longer available to the team for weeks. The team has long feedbackloops. Yes, and, that delivery arises from fast feedback cycles—fast learning. Software product development is about learning , first.
We organize all of the trending information in your field so you don't have to. Join 96,000+ users and stay up to date on the latest articles your peers are reading.
You know about us, now we want to get to know you!
Let's personalize your content
Let's get even more personalized
We recognize your account from another site in our network, please click 'Send Email' below to continue with verifying your account and setting a password.
Let's personalize your content