Tuesday, April 29, 2008
Product Management and Development: Friends with Benefits
Saeed Khan published an interesting post yesterday (http://onproductmanagement.wordpress.com/2008/04/29/agiledev_and_pm/ ). I enjoyed his perspectives, especially the comparison to Sales. It’s so true – when Sales adopts a new methodology, they do it independently, and we’re not expected to be involved. Why is it, then, that we get sucked into Development when they adopt a new approach? Better to be “friends with benefits” than to be constant companions!
Thursday, April 24, 2008
Product Manager: Hawk of the Market
This morning, I took my morning coffee to the front deck. It’s finally spring here (Wisconsin), and winter was so long that it actually feels strange not to cringe when you step outside. Well, the winter is finally really gone, despite holding on as long as possible. The last of the snow melted from the northern hillsides last week, and the grass will soon be calling to be mowed.
So I was outside, enjoying some fresh ground, extra-strong-just-the-way-I-like-it Kona coffee, and I spotted a huge Red-Tailed Hawk. She was perched in a large White Oak at the edge of the lawn, very still. The only reason I saw her is because the sun was shining from behind, and her body was bulkier than the surrounding branches.
I was almost finished with my first cup when she dove. With a powerful swing of the wings, the hawk swooped down, pursuing some prey that I couldn’t see from my vantage point.
She reached the ground, and was pretty obscured from my vision by the tall grass around her. After a few moments of getting situated, she took off with what appeared to be a mouse. Coffee for me, mouse tar tare for my red-tailed friend.
When a hawk is perching, one could believe that it’s at rest. If you watched long enough, you might even begin to think it’s lazy, just resting there surveying its surroundings.
It’s neither resting nor lazy. The hawk seeks just the right location, with the best perspective on the land. If she was looking sideways, she’d never see that small mouse or rabbit because they’d be hidden by vegetation. She’s got to get out of the fray, up to an elevation where she can see the whole landscape of possibility. The vantage point is crucial to the hawk’s hunt.
Product Managers have to get out of the fray, too. All that stuff that happens in the office is the ground vegetation, obstructing our view of the market at large. No matter how your development team functions, which methods or processes or tools they employ, the most important thing you can do is to get OUT of the office. Rise up out of the tall grass, and find a good perspective from a vantage point IN the market, not IN the office!
Be the hawk of the market, and remember that you can’t spot the next big opportunity if you’re bogged down in the tall grass inside your company’s four walls!
So I was outside, enjoying some fresh ground, extra-strong-just-the-way-I-like-it Kona coffee, and I spotted a huge Red-Tailed Hawk. She was perched in a large White Oak at the edge of the lawn, very still. The only reason I saw her is because the sun was shining from behind, and her body was bulkier than the surrounding branches.
I was almost finished with my first cup when she dove. With a powerful swing of the wings, the hawk swooped down, pursuing some prey that I couldn’t see from my vantage point.
She reached the ground, and was pretty obscured from my vision by the tall grass around her. After a few moments of getting situated, she took off with what appeared to be a mouse. Coffee for me, mouse tar tare for my red-tailed friend.
When a hawk is perching, one could believe that it’s at rest. If you watched long enough, you might even begin to think it’s lazy, just resting there surveying its surroundings.
It’s neither resting nor lazy. The hawk seeks just the right location, with the best perspective on the land. If she was looking sideways, she’d never see that small mouse or rabbit because they’d be hidden by vegetation. She’s got to get out of the fray, up to an elevation where she can see the whole landscape of possibility. The vantage point is crucial to the hawk’s hunt.
Product Managers have to get out of the fray, too. All that stuff that happens in the office is the ground vegetation, obstructing our view of the market at large. No matter how your development team functions, which methods or processes or tools they employ, the most important thing you can do is to get OUT of the office. Rise up out of the tall grass, and find a good perspective from a vantage point IN the market, not IN the office!
Be the hawk of the market, and remember that you can’t spot the next big opportunity if you’re bogged down in the tall grass inside your company’s four walls!
Thursday, April 17, 2008
The Agile "daily involvement" principle
The Agile Manifesto lays out sound principles for developing software. I mean, who could argue with valuing individuals and interactions over process and tools (from http://agilemanifesto.org/ )? It makes sense, and many engineers tell me that an agile approach is a more natural fit to the way they work.
There are lurking pitfalls, however. One of the principles of the agile manifesto, as stated at http://agilemanifesto.org/principles.html, is:
Business people and developers must work together daily throughout the project.
Let’s think about the intent behind this principle. It makes sense that Development needs to understand the business end – they need to get good information to help design great solutions.
Now, consider the way this is being interpreted. There are companies out there who will say that if your team is Agile, Product Management has to pick up additional tasks. They’ll say that the Product Manager needs to be the “business people” who is involved DAILY.
Theoretically, if we added more Product Management resources, we could cover daily interactions with Development and still gather fresh business information to drive into the development process. Theoretically, we could double staff – have one Product Manager out in the market, and the other working with Development.
Rather than focusing on turf wars between Marketing or Product Management and Development, let’s take a step back and think about the tasks involved in this daily interaction. Maybe there is a question about how to break down a user story into sprints. Perhaps there is a clarification needed about how the user will rely on a particular area. Certainly there are lots of activities involved in defining the user interface, in designing the solution.
Now, think about the best Product Managers. The best of the bunch are people who understand how to interview the market, how to tease out market problems worth solving and present them in a way that helps the organization understand the potential opportunities and risks. The best Product Managers spend most of their time interacting with the market. They are market experts.
They rely on teams of designers and engineers to be the technology and product experts. They rely on project management skills to break stuff down into sprints, and put it back together again.
If we take one of these folks and have them work internally, translating market requirements into sprints and helping design the user interaction, they are no longer a Product Manager! At that point, they are doing design.
Want to develop awesome products that excite your customers and cause them to recommend you to everyone they know? Hire skilled designers to do that work, and leave the Product Managers focused on the business. After all, design is a skill and an art – and so is Product Management.
There are lurking pitfalls, however. One of the principles of the agile manifesto, as stated at http://agilemanifesto.org/principles.html, is:
Business people and developers must work together daily throughout the project.
Let’s think about the intent behind this principle. It makes sense that Development needs to understand the business end – they need to get good information to help design great solutions.
Now, consider the way this is being interpreted. There are companies out there who will say that if your team is Agile, Product Management has to pick up additional tasks. They’ll say that the Product Manager needs to be the “business people” who is involved DAILY.
Theoretically, if we added more Product Management resources, we could cover daily interactions with Development and still gather fresh business information to drive into the development process. Theoretically, we could double staff – have one Product Manager out in the market, and the other working with Development.
Rather than focusing on turf wars between Marketing or Product Management and Development, let’s take a step back and think about the tasks involved in this daily interaction. Maybe there is a question about how to break down a user story into sprints. Perhaps there is a clarification needed about how the user will rely on a particular area. Certainly there are lots of activities involved in defining the user interface, in designing the solution.
Now, think about the best Product Managers. The best of the bunch are people who understand how to interview the market, how to tease out market problems worth solving and present them in a way that helps the organization understand the potential opportunities and risks. The best Product Managers spend most of their time interacting with the market. They are market experts.
They rely on teams of designers and engineers to be the technology and product experts. They rely on project management skills to break stuff down into sprints, and put it back together again.
If we take one of these folks and have them work internally, translating market requirements into sprints and helping design the user interaction, they are no longer a Product Manager! At that point, they are doing design.
Want to develop awesome products that excite your customers and cause them to recommend you to everyone they know? Hire skilled designers to do that work, and leave the Product Managers focused on the business. After all, design is a skill and an art – and so is Product Management.
Thursday, April 10, 2008
Death by Daily Stand-Up - a Chaotic Transition to Agile
When your development team goes agile, what happens to Product Management?
Too often, I talk with Product Managers who are now sucked into the internal world of development. They are taking part in daily stand-ups, helping to translate market requirements into feature sets and even sprints.
I am all for improvements in development methods, and I have seen agile work really well. I can also understand how development teams would prefer to have the Product Manager in the room – after all, we are the ones who know the market that Development’s trying to please. So, it’s not too hard to see how Product Managers end up spending every day interfacing with Development.
At what cost?
If the Product Manager is in the daily stand-up – if they’re learning enough about the technology to help plan the contents of sprints, if they’re participating faithfully in daily decisions – who is going to figure out what comes next?
If we expect Product Managers to focus internally, aren’t we dictating the eventual end of our companies? If Product Managers are in the building, who’s out finding the next big opportunity? The market’s going to change – how will we know what it needs next?
Too often, I talk with Product Managers who are now sucked into the internal world of development. They are taking part in daily stand-ups, helping to translate market requirements into feature sets and even sprints.
I am all for improvements in development methods, and I have seen agile work really well. I can also understand how development teams would prefer to have the Product Manager in the room – after all, we are the ones who know the market that Development’s trying to please. So, it’s not too hard to see how Product Managers end up spending every day interfacing with Development.
At what cost?
If the Product Manager is in the daily stand-up – if they’re learning enough about the technology to help plan the contents of sprints, if they’re participating faithfully in daily decisions – who is going to figure out what comes next?
If we expect Product Managers to focus internally, aren’t we dictating the eventual end of our companies? If Product Managers are in the building, who’s out finding the next big opportunity? The market’s going to change – how will we know what it needs next?
Thursday, April 3, 2008
A Smooth Transition to Agile
The first time I was managing a product where the Development team adopted agile methods, I didn’t even realize it until we had to deliver a bug fix. I was amazed to find that not only could we deliver the bug fix, but we also had the option of including additional functionality that had already been built and tested!
It takes two ingredients to make a smooth transition to using agile development methodologies to build products people want to buy.
First, the Product Manager needs to deliver a prioritized list of requirements. Those requirements have to focus on urgent, pervasive problems that people are willing to pay to have solved. They have to provide context so that Development understands enough to build the right solution.
Second, your Development team has to include a design role. SOMEONE needs to translate market problems into a specification. They need to design the right solution, and figure out how to break the work into sprints. This step needs to be done by people who understand the market requirements, and also understand how to design really good products.
If you are providing market-driven, prioritized requirements with appropriate context, and your Development team understands and respects the art of design, the switch to agile should be smooth….so smooth, you might not even notice!
It takes two ingredients to make a smooth transition to using agile development methodologies to build products people want to buy.
First, the Product Manager needs to deliver a prioritized list of requirements. Those requirements have to focus on urgent, pervasive problems that people are willing to pay to have solved. They have to provide context so that Development understands enough to build the right solution.
Second, your Development team has to include a design role. SOMEONE needs to translate market problems into a specification. They need to design the right solution, and figure out how to break the work into sprints. This step needs to be done by people who understand the market requirements, and also understand how to design really good products.
If you are providing market-driven, prioritized requirements with appropriate context, and your Development team understands and respects the art of design, the switch to agile should be smooth….so smooth, you might not even notice!
Subscribe to:
Posts (Atom)
