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.
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!
Tuesday, May 13, 2008
A Quick Toss Over the Wall -- Never Cool
This morning, I came across an interesting post. In it, Luke Hohmann of Enthiosys writes:
"Note also that we reject the notion that product management is somehow external from the development organization. Indeed, we're shocked when we hear of product management practices that assume the product manager can simply deliver an MRD to their development team and walk away, assuming that the process used by the development team does not affect product management. If you're a practicing Agile Product Manager, you're definitely not writing an MRD and walking away. "
I’d like to go a step further, and say that any product manager who understands technology and wants to succeed (and keep their job) is not writing any sort of requirement document and walking away.
Regardless of the development methodology in use, Product Managers need to describe and prioritize requirements for the team. In your first publication of the requirement, provide relevant context to help the team understand the market’s need. Tell them who the target persona is, what problem they’re experiencing, and how frequently this situation occurs. Sit down and review it with the product team. Make yourself available for questions during this period – they’re trying to understand the requirement and may need your help in that process. If your team finds a gap in your research and asks for more information, get it for them. As you get better at writing the requirement with appropriate context, your team will have fewer questions….allowing you to spend more time in the market, finding problems that will provide future revenue opportunities.
Throwing a requirements document over the wall has never been cool – it leaves the team in the dark, grasping around trying to figure out what is truly needed. Whether your team is agile or not, provide prioritized requirements with good context. Review with your team, and ensure that they understand the true market need. Two-way communication early in the cycle will help reduce the questions your team runs into later on – so be available, and work with the team until they understand the requirement well enough to design features and organize the iterations or sprints.
Then, walk away – while the team is building this release, go back to the market and continue researching. By the time this release is done, you’ll be ready with the next set of prioritized, context-rich requirements.
"Note also that we reject the notion that product management is somehow external from the development organization. Indeed, we're shocked when we hear of product management practices that assume the product manager can simply deliver an MRD to their development team and walk away, assuming that the process used by the development team does not affect product management. If you're a practicing Agile Product Manager, you're definitely not writing an MRD and walking away. "
I’d like to go a step further, and say that any product manager who understands technology and wants to succeed (and keep their job) is not writing any sort of requirement document and walking away.
Regardless of the development methodology in use, Product Managers need to describe and prioritize requirements for the team. In your first publication of the requirement, provide relevant context to help the team understand the market’s need. Tell them who the target persona is, what problem they’re experiencing, and how frequently this situation occurs. Sit down and review it with the product team. Make yourself available for questions during this period – they’re trying to understand the requirement and may need your help in that process. If your team finds a gap in your research and asks for more information, get it for them. As you get better at writing the requirement with appropriate context, your team will have fewer questions….allowing you to spend more time in the market, finding problems that will provide future revenue opportunities.
Throwing a requirements document over the wall has never been cool – it leaves the team in the dark, grasping around trying to figure out what is truly needed. Whether your team is agile or not, provide prioritized requirements with good context. Review with your team, and ensure that they understand the true market need. Two-way communication early in the cycle will help reduce the questions your team runs into later on – so be available, and work with the team until they understand the requirement well enough to design features and organize the iterations or sprints.
Then, walk away – while the team is building this release, go back to the market and continue researching. By the time this release is done, you’ll be ready with the next set of prioritized, context-rich requirements.
Thursday, May 8, 2008
The Backlog: One Idea; Three Definitions
There are so many terms in technology. That would not be a problem if language were a perfect science. Alas, it is not. Let’s just think about “product backlog.”
The Scrum Alliance provides this definition:
“The product backlog (or "backlog") is the requirements for a system, expressed as a prioritized list of product backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements”
Wikipedia says:
“The set of features that go into each sprint come from the product backlog, which is a prioritized set of high level requirements of work to be done.”
At Control Chaos, they say:
“Product Backlog (or, backlog) consists of all features, functions, technology, bugs that will constitute the product once the work has been done in Sprints to turn this backlog into software”
So, it looks like there is general agreement that the backlog is a prioritized list of things that need to get done in order to move our product in the right direction.
And yet – there is general chaos surrounding this artifact in most agile environments. We throw around terms like “requirements,” “features,” “functions,” and “technology” so frequently that they don’t really have a clear definition anymore. One’s definitions are dictated by our experiences and education, rather than any standard description that we can rely on.
To ensure clarity on our teams, it’s helpful to examine and discuss examples rather than terms.
Mike Kohn provided a few examples in a recently published article. The article is a good read with several good points. He explains that clarity should increase on backlog items as the sprint gets closer. If we have complex items, it makes sense to take time during prior sprints to figure out the full breadth of user stories, so that when we’re ready to work on this item we’re ready to go. Furthermore, he relies on a User Experience Designer to clarify the items. Let’s take a look at his examples.
Mike’s two examples of backlog items:
The Scrum Alliance provides this definition:
“The product backlog (or "backlog") is the requirements for a system, expressed as a prioritized list of product backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements”
Wikipedia says:
“The set of features that go into each sprint come from the product backlog, which is a prioritized set of high level requirements of work to be done.”
At Control Chaos, they say:
“Product Backlog (or, backlog) consists of all features, functions, technology, bugs that will constitute the product once the work has been done in Sprints to turn this backlog into software”
So, it looks like there is general agreement that the backlog is a prioritized list of things that need to get done in order to move our product in the right direction.
And yet – there is general chaos surrounding this artifact in most agile environments. We throw around terms like “requirements,” “features,” “functions,” and “technology” so frequently that they don’t really have a clear definition anymore. One’s definitions are dictated by our experiences and education, rather than any standard description that we can rely on.
To ensure clarity on our teams, it’s helpful to examine and discuss examples rather than terms.
Mike Kohn provided a few examples in a recently published article. The article is a good read with several good points. He explains that clarity should increase on backlog items as the sprint gets closer. If we have complex items, it makes sense to take time during prior sprints to figure out the full breadth of user stories, so that when we’re ready to work on this item we’re ready to go. Furthermore, he relies on a User Experience Designer to clarify the items. Let’s take a look at his examples.
Mike’s two examples of backlog items:
- As a user I can see the current version, company website, and copyright in a "help about" dialog so that I know useful information about the product.
- As a user I can enter a check in my register so that I can track who I pay.
These statements are already at the feature level. It doesn’t define exactly what the screens will look like, but someone has decided that important user information will go in a screen called “help about”. Likewise, someone has taken the time to start defining the necessary tasks included in managing a checkbook.
Where do these items come from?
When a Product Manager studies the market, they discover groups of people who share common problems. When they quantitatively analyze those problems, some are proven to be urgent, pervasive problems that people are willing to pay to solve.
The Product Manager’s primary job is to discover problems with these characteristics, then describe those problems to their organization. One part of their job is to define these problems for the Marketing and Sales organizations. The other part is defining the problems for Development, in a way that allows them to build the best possible solution, a solution that resonates in the marketplace and makes our target buyers come running.
For Mike’s example, he says that they’re building a checkbook program to compete with Quicken. I’m going to set aside the problem of entering an already swamped market and attempting to compete with the big boys. Let’s instead think about the Product Manager in this organization. If they’ve studied the market, perhaps they’ve found some problems that are urgent, pervasive, and have buyers willing to pay for a solution. The Product Manager would analyze the market evidence, and eventually write requirements. These requirements state that “Every [frequency], [persona] has [problem] with [result].”
Restating the earlier example: Once or twice in a year and usually on the initial visit, Sally the Soccer Mom wants to know more about the company, including where they are located physically and how they can be reached electronically. She needs this information when she has a problem with the product, or when she decides to upgrade.
In Mike’s fictional company, another primary requirement might state “At least once a week, Sally the Soccer Mom needs to figure out her current checking balance so that she knows if she needs to transfer money into the account. Otherwise, she might bounce a check or get charged overdraft fees.”
An interaction designer could take this requirement (along with the fully defined description of the persona, Sally the Soccer Mom), and design an interface that solves the defined problem. One item would be that the user needs to enter checks she has written. That capability is necessary in order to provide a current balance and solve her real problem – she doesn’t want to bounce a check or pay overdraft fees.
How often have you already envisioned the solution before you’ve stated the problem? Begin with the problem-oriented requirement: “Every [frequency], [persona] has [problem] with [result].” Then work with a user interaction designer or business analyst to define the solution.
If you define product backlog items at the level presented in Mike’s example, you’ll need a user interaction designer to translate the requirements into the product backlog items – otherwise, the Product Manager is being asked to focus internally, when our company is much better served by our presence in the market.
Thursday, May 1, 2008
Let's talk about the "backlog"!
Since the backlog is the prioritized list of necessary work, it’s pretty natural for some teams to assign its maintenance to the Product Manager. At first glance, that seems to make sense….but then, we begin diving in and realize that perhaps, there is a better way.
Take a look at your team’s backlog. Is it features? Or, even finer-grained tasks than that?
A Product Manager’s primary responsibility is to know the market – to discover urgent, pervasive problems that people are willing to pay to have solved.
We are generally not trained or necessarily skilled in the area of design.
A good Product Manager understands that good design is an integral part of a successful offering. We are, perhaps, capable of learning how to do design – and if necessary, we will give it our best shot.
Is that the best choice for our companies?
I want to buy products that surprise me with their simplicity and power – products that make me say, “Wow!” or “This is so obvious – why didn’t anyone do this before?”
In order to develop outstanding solutions, skilled designers must be focused on the problems we need to solve for the market. The designer should understand the problems that product management has identified. They must guide the design, closely working with development to ensure feasibility.
The designer should be in charge of the translation of market requirements into features. In an agile environment, that means that the designer must work with the Product Manager to understand the market requirements and their priority –and then lead the team to turning the problems into features and sprints that make sense. This must be done in close conjunction with the project manager, to ensure that the product that comes out the backend makes sense, and provides maximum impact in the target market segment.
People buy products that were designed by expert designers, not expert product managers!
Take a look at your team’s backlog. Is it features? Or, even finer-grained tasks than that?
A Product Manager’s primary responsibility is to know the market – to discover urgent, pervasive problems that people are willing to pay to have solved.
We are generally not trained or necessarily skilled in the area of design.
A good Product Manager understands that good design is an integral part of a successful offering. We are, perhaps, capable of learning how to do design – and if necessary, we will give it our best shot.
Is that the best choice for our companies?
I want to buy products that surprise me with their simplicity and power – products that make me say, “Wow!” or “This is so obvious – why didn’t anyone do this before?”
In order to develop outstanding solutions, skilled designers must be focused on the problems we need to solve for the market. The designer should understand the problems that product management has identified. They must guide the design, closely working with development to ensure feasibility.
The designer should be in charge of the translation of market requirements into features. In an agile environment, that means that the designer must work with the Product Manager to understand the market requirements and their priority –and then lead the team to turning the problems into features and sprints that make sense. This must be done in close conjunction with the project manager, to ensure that the product that comes out the backend makes sense, and provides maximum impact in the target market segment.
People buy products that were designed by expert designers, not expert product managers!
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)
