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.
Monday, July 28, 2008
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.
Thursday, May 15, 2008
When They Really Know Me
We are technology Product Managers. Our Developers are using agile. We are busy fighting the momentum that would draw us into the minutia of detailed planning meetings and attempt to make Designers out of unsuspecting Product Managers.
This is not always a high reward position – the organization seems to fight us every step of the way. Our teams imply that we’re letting them down, that we should be personally involved in the planning of each sprint. Even when we KNOW that we need to get out in the market, it’s difficult to fight the tide every day.
And yet – think about the last outstanding experience you had as a customer. Aren’t they always based on the fact that the company seems to know you, to intimately understand who you are and what you need to be successful?
I use Netflix. If you watch movies and want a convenient way to receive them, you should check it out. Netflix is unique among video rental companies because they send the DVD right to my house, built on the movie queue that my son and I build.
That uniqueness is what attracted me to this service. I live about 15 minutes from the nearest video rental store. I used to run out and get a DVD, and it would take close to an hour of my time (considering drive time and the selection period). Now, I’ve always got something at home if I want to watch, and it’s delivered right to my mailbox….so all I have to do is make it to the end of the driveway!
When they send the DVD, it’s in a red envelope that’s specially designed so that you can send it back in the same envelope it came in. There’s no postage to affix, so the process is really simply.
The week before last, I was getting ready for a business trip, and the only DVD in the house was Madagascar….amusing, and certainly a favorite of my son’s – but not one I wanted to take on the road with me! I wanted to send it back and get the next one in my queue, but the red envelope had mysteriously disappeared.
This was a moment of truth for Netflix. I procrastinated for a few days, because customer service is generally bad so I figured I needed to handle this when my patience was high.
Well, I finally sat down and searched online. In about 15 seconds, I had found an entry that said I could send the DVD back to the address supplied. OK, that would involve a trip to town, AND into the post office….so I found the Netflix number.
When I found it, I was surprised immediately. On the screen, they displayed the customer service number. They also displayed a reference ID for me to use, and the approximate wait time! Awesome -- before I even called, I knew how long I should plan for.
I called the number, and entered my reference ID. The wait time online was listed as 5 minutes. It was actually only about 3 minutes before an ACTUAL voice came on the line. He apparently had access to the reference ID I had entered, because he did not ask me for my account number (which I don’t know), my social security number (which I don’t want to share), or even my name. Michael knew who I was, and immediately asked what I needed today.
I began to explain that I had misplaced the red envelope. I was prepared to be blown off, as I’ve been trained by all of the overwhelmingly bad customer service we deal with every day.
What a pleasant surprise! Michael immediately understood that I did not want to go find an envelope, figure out the right postage, and go to the post office. He added a bonus DVD to my account and immediately shipped it out. That way, I could just put 2 DVDs back in the envelope when I was done watching.
He did NOT assume that I was trying to rip him off.
He did NOT tell me to find the answer online.
He did NOT make me explain the situation in depth.
As soon as he knew my issue, he understood what I needed and gave me an easy solution.
I was attracted to Netflix for the product they offer. I am staying because they are a market-driven company, a TunedIn business. I walked away feeling like they really knew my problems and situation – I didn’t want to be on the phone a long time, I just wanted a solution.
This is the reason that Product Managers must stay in the market! No one can build, support, or service our products properly unless they really understand our target buyers and users. Product Managers need to provide that context, so that our customers end up WANTING to buy more stuff from us!
This is not always a high reward position – the organization seems to fight us every step of the way. Our teams imply that we’re letting them down, that we should be personally involved in the planning of each sprint. Even when we KNOW that we need to get out in the market, it’s difficult to fight the tide every day.
And yet – think about the last outstanding experience you had as a customer. Aren’t they always based on the fact that the company seems to know you, to intimately understand who you are and what you need to be successful?
I use Netflix. If you watch movies and want a convenient way to receive them, you should check it out. Netflix is unique among video rental companies because they send the DVD right to my house, built on the movie queue that my son and I build.
That uniqueness is what attracted me to this service. I live about 15 minutes from the nearest video rental store. I used to run out and get a DVD, and it would take close to an hour of my time (considering drive time and the selection period). Now, I’ve always got something at home if I want to watch, and it’s delivered right to my mailbox….so all I have to do is make it to the end of the driveway!
When they send the DVD, it’s in a red envelope that’s specially designed so that you can send it back in the same envelope it came in. There’s no postage to affix, so the process is really simply.
The week before last, I was getting ready for a business trip, and the only DVD in the house was Madagascar….amusing, and certainly a favorite of my son’s – but not one I wanted to take on the road with me! I wanted to send it back and get the next one in my queue, but the red envelope had mysteriously disappeared.
This was a moment of truth for Netflix. I procrastinated for a few days, because customer service is generally bad so I figured I needed to handle this when my patience was high.
Well, I finally sat down and searched online. In about 15 seconds, I had found an entry that said I could send the DVD back to the address supplied. OK, that would involve a trip to town, AND into the post office….so I found the Netflix number.
When I found it, I was surprised immediately. On the screen, they displayed the customer service number. They also displayed a reference ID for me to use, and the approximate wait time! Awesome -- before I even called, I knew how long I should plan for.
I called the number, and entered my reference ID. The wait time online was listed as 5 minutes. It was actually only about 3 minutes before an ACTUAL voice came on the line. He apparently had access to the reference ID I had entered, because he did not ask me for my account number (which I don’t know), my social security number (which I don’t want to share), or even my name. Michael knew who I was, and immediately asked what I needed today.
I began to explain that I had misplaced the red envelope. I was prepared to be blown off, as I’ve been trained by all of the overwhelmingly bad customer service we deal with every day.
What a pleasant surprise! Michael immediately understood that I did not want to go find an envelope, figure out the right postage, and go to the post office. He added a bonus DVD to my account and immediately shipped it out. That way, I could just put 2 DVDs back in the envelope when I was done watching.
He did NOT assume that I was trying to rip him off.
He did NOT tell me to find the answer online.
He did NOT make me explain the situation in depth.
As soon as he knew my issue, he understood what I needed and gave me an easy solution.
I was attracted to Netflix for the product they offer. I am staying because they are a market-driven company, a TunedIn business. I walked away feeling like they really knew my problems and situation – I didn’t want to be on the phone a long time, I just wanted a solution.
This is the reason that Product Managers must stay in the market! No one can build, support, or service our products properly unless they really understand our target buyers and users. Product Managers need to provide that context, so that our customers end up WANTING to buy more stuff from us!
Subscribe to:
Posts (Atom)
