Tuesday, September 9, 2008
Skip the Daily Stand-Up
I just got back in from vacation, and began catching up on my e-mail and reading. The Cranky Product Manager wrote a great post, describing why it’s not practical for the Product Manager to participate in every Agile meeting ever held! The Cranky Product Manager hit this one on the head – if we are in the building, who will figure out what to do next? In an Agile world, it’s easy for Product Managers to get sucked into the development cloud. To succeed, we have to be aware of that tendency, and fight it…or we will quickly lose touch with the market that we’re supposed to be serving!
Monday, July 28, 2008
What’s the Cross-Functional Team, and Why should I have one?
I’ve been contemplating the soft skills that Product Managers need to succeed. My last post touched on one of those skills – translating between the varied members of our team. Today, I’ve been thinking about the cross-functional team and Product Management’s interaction in it.
First off, you should have a cross-functional team for your product. This group can provide valuable support and feedback for all its members. For Product Managers, the team provides considerable benefits. It helps us communicate more broadly, gain alignment more easily, and build better products (hardware, software, and/or services).
When I talk with product managers, and “their team” comes up, they often begin by thinking of their development team – those who actually build the product. The Product Manager enables the development team to succeed, by doing and documenting great market research and writing clear, prioritized requirements. The development team is (obviously) important, building amazing solutions that make people want to buy. However, there is another team that we must consider. Today when I talk about the team, I’m referring to the “cross-functional team”. It’s a much broader concept than a development team, and rather than the pure technology that’s built in Development, it’s focused on the whole solution – technology, marketing, sales, support, professional services, production, localization….any department who spends time helping our product succeed. A cross-functional team can be a powerful tool for the agile product manager.
The cross-functional team is a group of people who collectively represent the entire organization’s interests in a specific product or product family. This team provides benefits for the individuals on the team, the product and its customers, and the organization at large.
For the individual, the team is a support group and cheer section. It’s a place where the individual can easily get updated information for their department, and it’s an environment where each individual is safe in bringing up issues or roadblocks that they’re encountering. The group can help solve issues that are impacting any department. And, when there is positive news to share (e.g., reduction in call volume in tech support, increase in sales revenue, development milestones completed on time within budget), it’s a group who will celebrate successes. All of this results in increased job satisfaction and motivation for team members.
The product and its customers will benefit from the cross-functional team as well, because it can inspire ongoing improvements in product quality. Team members provide input throughout the product life cycle, and also bring issues to the attention of the team for resolution. When the team is assembled appropriately, and meetings are run effectively, we see improvements in customer satisfaction due to increases in product quality and support.
A healthy team improves organizational alignment. Members are kept “in the know” regarding product status, including market research, customer feedback, product development progress, product-related financials, and promotional plans and events. Each member is held responsible for bringing that information back to their own department or team. In addition, they feed the team their own department or team’s feedback. The cross-functional team allows us to get one representative group aligned; in turn, they exponentially increase organizational awareness and alignment.
Assembling a cross-functional team and leading with market facts is the domain of the Product Manager. A strong team results in increased job satisfaction and motivation for the individual, improvements in product quality (and therefore customer satisfaction), and elevated awareness and alignment for the organization.
First off, you should have a cross-functional team for your product. This group can provide valuable support and feedback for all its members. For Product Managers, the team provides considerable benefits. It helps us communicate more broadly, gain alignment more easily, and build better products (hardware, software, and/or services).
When I talk with product managers, and “their team” comes up, they often begin by thinking of their development team – those who actually build the product. The Product Manager enables the development team to succeed, by doing and documenting great market research and writing clear, prioritized requirements. The development team is (obviously) important, building amazing solutions that make people want to buy. However, there is another team that we must consider. Today when I talk about the team, I’m referring to the “cross-functional team”. It’s a much broader concept than a development team, and rather than the pure technology that’s built in Development, it’s focused on the whole solution – technology, marketing, sales, support, professional services, production, localization….any department who spends time helping our product succeed. A cross-functional team can be a powerful tool for the agile product manager.
The cross-functional team is a group of people who collectively represent the entire organization’s interests in a specific product or product family. This team provides benefits for the individuals on the team, the product and its customers, and the organization at large.
For the individual, the team is a support group and cheer section. It’s a place where the individual can easily get updated information for their department, and it’s an environment where each individual is safe in bringing up issues or roadblocks that they’re encountering. The group can help solve issues that are impacting any department. And, when there is positive news to share (e.g., reduction in call volume in tech support, increase in sales revenue, development milestones completed on time within budget), it’s a group who will celebrate successes. All of this results in increased job satisfaction and motivation for team members.
The product and its customers will benefit from the cross-functional team as well, because it can inspire ongoing improvements in product quality. Team members provide input throughout the product life cycle, and also bring issues to the attention of the team for resolution. When the team is assembled appropriately, and meetings are run effectively, we see improvements in customer satisfaction due to increases in product quality and support.
A healthy team improves organizational alignment. Members are kept “in the know” regarding product status, including market research, customer feedback, product development progress, product-related financials, and promotional plans and events. Each member is held responsible for bringing that information back to their own department or team. In addition, they feed the team their own department or team’s feedback. The cross-functional team allows us to get one representative group aligned; in turn, they exponentially increase organizational awareness and alignment.
Assembling a cross-functional team and leading with market facts is the domain of the Product Manager. A strong team results in increased job satisfaction and motivation for the individual, improvements in product quality (and therefore customer satisfaction), and elevated awareness and alignment for the organization.
Wednesday, July 23, 2008
The Product Manager – Translator Extraordinaire
Whenever I travel outside the U.S., I am struck by the number of people who speak multiple languages fluently. On one particular trip, I was in the Brussels airport. The ticket counter agent was speaking at least 4 languages – and she knew them so well that she could quickly switch between them. She’d get someone checked in using French, then turn around and answer a quick question in German. She spoke to me in near perfect English, and as I was walking away I heard her speaking Spanish (or perhaps Portuguese) to another passenger.
For awhile, I would kind of beat myself up over this -- my Spanish is pretty rusty, and I would definitely not say I’m fluent. I often wish I knew at least one other language – it’s so much more personal to greet people in their native tongue, rather than expecting the whole world to speak English.
Upon further consideration, I decided I was being too hard on myself. After all, don’t we Product Managers translate constantly for our organizations? I may not know French, German, Chinese, Flemish, or Hindi – but I do understand Sales-speak, Development-dialect, Promotions-patois, and Operations-oracy.
We do translations all the time. The agile product manager is skilled at understanding each member of the team, so they can translate for others.
When Sales says “If I could only get this feature in the release, I’d close this deal,” they actually mean, “I feel like I’m losing here, and surely it cannot be my fault.” The Product Manager’s job is to help the team understand, and to keep them focused on their current work. If a Sales person makes a statement like that directly to development, without any translation, the team might believe the rhetoric, and quickly switch to satisfying one sales person. The Product Manager needs to help everyone see the market clearly and objectively.
When Development says “we’re delivering a new architectural layer that will dynamically expose all data elements”, the Product Manager needs to intercept, and ensure that the Promotions team understands the benefits of the release, rather than the technological miracle that happens under the covers.
The biggest battle in doing this translation is to give ourselves a moment to think. Where did the statement come from, and who else needs to understand it? Think about the Development explanation from above – they are speaking from their very technical viewpoint. Promotions, however, needs to understand the benefit to the buyer and/or user.
Early on in my career, I did a lot of this translation on the fly. Later, I learned that much of this translation can be ‘canned’, by anticipating the needs of each department and communicating to them so that their primary concerns are placed front and center. In the case of Promotions, positioning is the preferred method of translation – we use positioning to move us away from the technical, into laser-focus on the market’s problems and our solutions to those problems. We can do that translation up front, so the Promotions team can continue to focus on the benefit, without getting distracted by Development details. The secondary benefit is that we don’t have to spend quite as much time being personally involved in reviewing early versions of the Promotional artifacts. In fact, with a good positioning statement, MarCom is free to operate independently – creating high impact promotions with minimal daily involvement by the Product Manager.
We translate for our teams every day. When we focus on that necessity, we can do some of the work up front, and ensure that each member has what they need to be really good at their job. In turn, we can continue to create, market, and sell current products effectively…while we return to the market, analyzing its problems and prioritizing requirements for the next big thing.
For awhile, I would kind of beat myself up over this -- my Spanish is pretty rusty, and I would definitely not say I’m fluent. I often wish I knew at least one other language – it’s so much more personal to greet people in their native tongue, rather than expecting the whole world to speak English.
Upon further consideration, I decided I was being too hard on myself. After all, don’t we Product Managers translate constantly for our organizations? I may not know French, German, Chinese, Flemish, or Hindi – but I do understand Sales-speak, Development-dialect, Promotions-patois, and Operations-oracy.
We do translations all the time. The agile product manager is skilled at understanding each member of the team, so they can translate for others.
When Sales says “If I could only get this feature in the release, I’d close this deal,” they actually mean, “I feel like I’m losing here, and surely it cannot be my fault.” The Product Manager’s job is to help the team understand, and to keep them focused on their current work. If a Sales person makes a statement like that directly to development, without any translation, the team might believe the rhetoric, and quickly switch to satisfying one sales person. The Product Manager needs to help everyone see the market clearly and objectively.
When Development says “we’re delivering a new architectural layer that will dynamically expose all data elements”, the Product Manager needs to intercept, and ensure that the Promotions team understands the benefits of the release, rather than the technological miracle that happens under the covers.
The biggest battle in doing this translation is to give ourselves a moment to think. Where did the statement come from, and who else needs to understand it? Think about the Development explanation from above – they are speaking from their very technical viewpoint. Promotions, however, needs to understand the benefit to the buyer and/or user.
Early on in my career, I did a lot of this translation on the fly. Later, I learned that much of this translation can be ‘canned’, by anticipating the needs of each department and communicating to them so that their primary concerns are placed front and center. In the case of Promotions, positioning is the preferred method of translation – we use positioning to move us away from the technical, into laser-focus on the market’s problems and our solutions to those problems. We can do that translation up front, so the Promotions team can continue to focus on the benefit, without getting distracted by Development details. The secondary benefit is that we don’t have to spend quite as much time being personally involved in reviewing early versions of the Promotional artifacts. In fact, with a good positioning statement, MarCom is free to operate independently – creating high impact promotions with minimal daily involvement by the Product Manager.
We translate for our teams every day. When we focus on that necessity, we can do some of the work up front, and ensure that each member has what they need to be really good at their job. In turn, we can continue to create, market, and sell current products effectively…while we return to the market, analyzing its problems and prioritizing requirements for the next big thing.
Tuesday, July 8, 2008
Going agile? Consider this.
Companies are like machines. Each department plays their part, and together the thing somehow works. People within one department don’t always have to understand the entire operation – Sales people, for instance, are not required to understand how coding actually happens.
Certain organizational changes happen, and force the departments to understand a bit more about the machine. For instance – if Sales people are asked to begin selling a product that is delivered as an API, they’re probably going to have to learn something about coding (even if it’s just enough to explain the benefits of their solution).
Usually, Development can make adjustments to their process without needing the support or understanding of other departments. They change the process for controlling source code – but no one else has to deal with that, so it’s an isolated change within their department. Or, they go from manual testing to automation. Again, no one else needs to understand that change (as long as quality is positively impacted).
In most companies, changing to agile is not isolated. When the process for receiving requirements and estimating work changes, lots of areas in the company are impacted and must be brought on board. Basically, this change can cause stress in other parts of the company. If Product Management was having a hard time keeping up before, the change to agile will highlight that weakness, and sometimes stretch our process so far that it actually breaks.
If your development team is thinking of going agile, you have to stop and examine your requirements process. Are you ready to live in an agile world?
How are you preparing requirements? Do you constantly update the prioritized list of market requirements? Or, do you get to a point where you realize you have to deliver requirements, and quickly scramble your schedule so you have time to write stuff down before the team wants to review?
If I asked you to give me your top two requirements tomorrow morning, could you do it?
This is what Product Managers have to be prepared for! When your team goes agile, you have to constantly maintain the prioritized requirements, so you can give development more work at any time.
An agile team is going to ask for requirements more frequently, since they’re organizing their work into short sprints rather than a long waterfall release cycle. If you are constantly seeking market input, and organizing that input into a prioritized list of market requirements, you should be able to handle the transition fairly easily.
If your developers are transitioning to agile, take a look at your machine. Oil as needed, so that your team is enabled to succeed in an agile world.
Thursday, June 5, 2008
Requirements - Discover, not Gather!
Over the years, I have found that I always have an internal screech when someone uses the term “requirements gathering”. The term itself makes it seem like the requirements are lying there, and the Product Manager just has to grab them and pop ‘em in a document. If we were creating custom solutions, the phrase might be more accurate – all of the users would be identifiable, and we could truly gather requirements from them. We’d still need to design the product in ways the user couldn’t even imagine, but with a limited and fully identified group of users the job would be pretty straight-forward.
The requirements beast changes its face when we’re building commercial solutions. We define a market segment, to help narrow the field of potential users. Then, we have to find potentials in that market segment, and watch them in their environment. We need to interview them, to really get to know their situations. And, we need to find ways to sample the segment at large, to find out how pervasive problems really are across the segment.
Each potential we visit may use slightly different ways of expressing their problems. The adjacent systems may vary from one location to another. Some problems only occur in parts of the market segment, and the problems sometimes seem to vary greatly.
Product Managers must study all of this information, and somehow discern which problems are most important. We have to narrow our field of vision from “all possible requirements” down to sets of problems that, when solved, will incent people to spend money. Only then can we actually document the requirement (Every [frequency], [persona] has [problem].) and clearly guide our teams to build a product that’s worth our time and energy.
To build awesome commercial solutions that people want to buy, we can’t just GATHER requirements – we have to study the market, and analyze their problems. Requirements aren’t gathered, they are DISCOVERED through our analysis of market evidence. Then, they are written with the right context to improve communication to our teams, helping our teams build outstanding solutions that resonate in the market.
What do you call the process of discovering requirements?
The requirements beast changes its face when we’re building commercial solutions. We define a market segment, to help narrow the field of potential users. Then, we have to find potentials in that market segment, and watch them in their environment. We need to interview them, to really get to know their situations. And, we need to find ways to sample the segment at large, to find out how pervasive problems really are across the segment.
Each potential we visit may use slightly different ways of expressing their problems. The adjacent systems may vary from one location to another. Some problems only occur in parts of the market segment, and the problems sometimes seem to vary greatly.
Product Managers must study all of this information, and somehow discern which problems are most important. We have to narrow our field of vision from “all possible requirements” down to sets of problems that, when solved, will incent people to spend money. Only then can we actually document the requirement (Every [frequency], [persona] has [problem].) and clearly guide our teams to build a product that’s worth our time and energy.
To build awesome commercial solutions that people want to buy, we can’t just GATHER requirements – we have to study the market, and analyze their problems. Requirements aren’t gathered, they are DISCOVERED through our analysis of market evidence. Then, they are written with the right context to improve communication to our teams, helping our teams build outstanding solutions that resonate in the market.
What do you call the process of discovering requirements?
Monday, June 2, 2008
Is Cherry-Picking Bad?
The long Memorial Day weekend was nice, and the weather is finally decent in Wisconsin. The grass is growing faster than I can mow it, and the birds are thick. Last week, the woodcocks were peenting most of the night, and the owl calls have begun. The oaks are finally leafed out, and the wild geraniums are blooming everywhere. All this means that I am distracted, as you can probably tell by the lack of posts this past week! It’s not that I’m not working – it’s just that I haven’t had a really high concentration level. This week, it’s back to business – the birds are tuned out and I am catching up on my reading.
Last week, I found myself cherry-picking from my to do list. I finished quite a few things…light-weight items that didn’t require a lot of concentration. I travel a lot, and find it most beneficial to do these low-concentration tasks for my first few days back in the office. My mind needs to rest and re-acclimate before I can focus.
I can organize my workload appropriately, so that I can cherry-pick the easier stuff when my mind isn’t prepared to focus. I can get away with that for a week or so, max. After that, I have to go back to high-concentration items, because the light-weight tasks are done for now and the meatier items need to be addressed.
One of the best parts of my job is that I get to talk with a lot of Product Managers. One common complaint is that their agile development team is cherry-picking items during the sprint. We turn over requirements, and development creates a sprint from the highest priority group. Our developers are often optimistic about schedules. During the sprint, some things don’t get done. I often hear a suspicion in these teams – suspicion that the development team works on the items that seem most fun, and don’t make it to the “other” items. That’s like if I cherry-pick from my to do list, and never quite make it to the higher-concentration items.
This behavior during an individual sprint does not bother me. In fact, I don’t really care how the development team’s work is organized – as long as they are addressing requirements in descending priority order. I understand that sometimes, we overestimate capacity and don’t complete everything that was planned for the sprint. All I ask is that the next sprint begins with the leftover tasks, so that they continue working in descending priority order.
Our teams should finish ALL the items planned for one sprint, before moving on to the next group of requirements. If we’ve done our jobs as product managers, the current iteration includes the highest priority requirements. If the team gets to the end of the sprint and they haven’t finished all the work, the next sprint should begin with the leftover items. Cherry picking is OK for a little while, but eventually we have to go back and finish the stuff we skipped. It’s a good rule for personal organization, and it’s crucial when developing commercial software in an agile world.
Tuesday, May 20, 2008
Fighting Internal Gravity
It’s an interesting dilemma – our development team pulls us in, often because they don’t have the information (target user personas and their problems) they need to proceed. And in order to get the information they need, we have to leave the building. The internal momentum in this situation is strong...the development team needs to keep working, and it's really hard to write requirements when we haven't been in the market. So we try to write some, but they're not very good and consequently the team has lots of questions. This creates a strong gravitational pull, and it can be hard to break it and find the time to research the market.
Start somewhere! Pick a half-day, and go see a customer. Read an industry publication you’re not familiar with. When you go to the annual sales meeting, stay an extra day, and visit a customer you’ve never met before.
After all, getting into the market and orienting ourselves toward its needs is of ultimate importance. As my colleague and friend, Steve Johnson, says, “failure is likely when delivering products without market knowledge.”**
The future of our products and our companies is in our hands, so it’s essential to find the time to get out into the market.
How do you find opportunities to get into the market? What have you learned about fighting internal gravity?
**Steve Johnson’s eBook, The Strategic Role of Product Management, is now available. I truly enjoy Steve’s comments and perspectives – in addition to being absolutely hilarious, he is a bright and experienced professional with a deep knowledge of technology and product management. Many technology companies struggle to define roles and relationships between departments. This eBook can be a handy reference to begin discussing and resolving questions of ownership and purpose for Product Managers.
Start somewhere! Pick a half-day, and go see a customer. Read an industry publication you’re not familiar with. When you go to the annual sales meeting, stay an extra day, and visit a customer you’ve never met before.
After all, getting into the market and orienting ourselves toward its needs is of ultimate importance. As my colleague and friend, Steve Johnson, says, “failure is likely when delivering products without market knowledge.”**
The future of our products and our companies is in our hands, so it’s essential to find the time to get out into the market.
How do you find opportunities to get into the market? What have you learned about fighting internal gravity?
**Steve Johnson’s eBook, The Strategic Role of Product Management, is now available. I truly enjoy Steve’s comments and perspectives – in addition to being absolutely hilarious, he is a bright and experienced professional with a deep knowledge of technology and product management. Many technology companies struggle to define roles and relationships between departments. This eBook can be a handy reference to begin discussing and resolving questions of ownership and purpose for Product Managers.
Subscribe to:
Posts (Atom)
