Pragmatic Marketing - Articles - RequirementsPragmatic Marketing - Articleshttp://pragmaticmarketing.com/agility_articles/redirecten-usAgility CMSMon, 10 Jul 2017 14:44:42 -0400http://pragmaticmarketing.com/agility_articles/redirect?id=21631http://feeds.feedblitz.com/~/288529516/0/pragmaticmarketing/articles/requirements~Go-Agile-With-MarketDriven-User-StoriesGetting a product to the market is hard. You might think that the hardest part is building the product itself, but I think the most challenging part is deciding what to build in the first place. Specifically, articulating what to build and why it’s important. For some product people, agile makes articulating requirements even harder. However, responding to change and breaking big things down into small things is exactly what we must do to deliver products the market will love as early as possible. And so I believe that agile is an opportunity to connect to the market, strengthen product requirements and get buy-in.

How do we accomplish this?

Listen to the market. Understand the problems, their pervasiveness and the context around these problems.

Turn that understanding into concise, relatively large problems and prioritize them.

Collaboratively break those problems down into user stories that the team can build.

Organize your problems and stories into a flexible problem-oriented roadmap that ideally targets specific personas with each release.

With each iteration big and small, funnel feedback into your roadmap as new problems or stories.

To start, get out of the office and engage with buyers and users in the marketplace. Interview them to find out what makes them tick, what keeps them up at night, what they read and who they follow. Pragmatic Marketing calls these NIHITO Visits (nothing important happens in the office). This activity will give you qualitative data that you can validate quantitatively through surveys and market analysis. Take these learnings and build personas, the representatives of your market.

Armed with market facts, you can now define the problem. Analyze your market data and personas, and look for patterns among them. These patterns will reveal market problems that are both urgent and pervasive. Write problem statements that describe the issue and include the emotional cost to the user and the frequency. Using your NIHITO visits, tally the number of times you have witnessed this problem in the market (be prepared to have examples in case you are challenged by stakeholders). Rate the business value of the market opportunity to your customers, and compare it to other problems you could solve.

At a previous company, we knew we needed to rebuild of our flagship product. Prior to development, we spent months interviewing potential and existing customers to discover the problems with our existing tool.

We discovered that it was a huge pain for our veteran users to use the wizard every time they set up a new job. We had thought the wizard would be a great way to ensure that users ticked all the boxes, but we failed to realize that it forced users to do things they didn’t need to do. We communicated the issue to the wider development team and collaboratively approached our user stories with this problem in mind. The result? We focused our user stories on keeping options open to the user, but not mandating them.

Getting feedback on working software is important in agile. We tested an early prototype on a small group of new and veteran users. We gave them a broad description of the goal and asked users to set up jobs. As we watched nervously, we learned that when we removed too much guidance from the process, both new and advanced users got lost. They enjoyed the open interface that allowed them to access the features that matter most to them, but whenever they set up new jobs, they didn’t know where to start or what to do next.

To strike a balance, we implemented a checklist that gently coached each user on what to do next without forcing them down a specific path. We implemented this into the next iteration; our focus group tested it and loved it.

So why didn’t I just tell development the solution I wanted built? Articulating problems rather than features frees engineers and designers to choose the right technology and design to solve the problem. Moreover, you have no idea if a feature is suitable for the market unless the users actually use it. Articulating problems rather than features avoids locking the team into technology that fails to achieve user goals. Placing the problem at the forefront keeps the organization focused on solving the user’s problem rather than the tools needed to do it.

Once you understand the problem’s frequency, business value and projected effort, you can prioritize market problems with the goal of solving the most urgent and pervasive ones first.

Organize the prioritized problems into releases that target each persona. Driven by urgency and market data, the teams will first build what matters most. This roadmap makes it easy for stakeholders (especially nontechnical ones) to understand who you are targeting, why and the order, all based on market facts. This also helps sales and marketing teams develop messaging that focuses on each persona.

Market problems are big and can’t be built in a single increment. So how can you be sure that your solution will solve the problem? A major goal in agile is to take big concepts and break them down into fully functioning product increments, then adjust the plan/product based on user feedback. In scrum methodology, you could apply market problems to epics. Epics are a collection of user stories that achieve a larger user goal. You can collaborate with design and development to break the market problem down into smaller user stories that contribute to solving the problem.

Typically, user stories are structured as mini problems: As [persona], I need to [what the user needs in their words] so that I can [the solution’s benefit]. Persona documents help guide the team to make the right decisions about the user’s needs and ensure they stay aligned to the market. Though it is a collaborative effort, you are responsible for getting the stories written, prioritized and understood.

For instance, a user story for the veteran users of the flagship product at my previous company might look like this: As Jen the IT analyst, I need to have a streamlined process that doesn’t ask unnecessary questions, so that I can set up new jobs without a lot of repetition. By attaching the persona to your user story, you provide context.

Most agile teams work to deliver a product in small increments called sprints (typically a one-to-three-week period). The design/development team commits to deliver a collection of stories that align with a sprint goal. This keeps the team focused on solving a specific set of small problems, resulting in working software that solves the overall goal for that sprint.

Since the team delivers fully functioning, tested product increments each sprint, you can now obtain user feedback on each product increment. Review the feedback with designers and developers. Better yet, have a designer and developer tag along to watch the user use it. Turn the feedback into new user stories. As you build the product, you may modify market problems or discover new ones. Remember, the roadmap must be flexible.

Are you beginning to see how everything connects? User stories are driven by the persona’s smallest need. A collection of user stories are built to meet a sprint goal. Multiple sprint goals combine into releases that are targeted to a specific persona. Single or multiple releases combine to solve the market’s problem.

It’s all driven by market data straight from the user. Iterating as you go, the product constantly evolves based on user feedback while still solving the primary problem. Articulating problems instead of specific technologies/features keeps the team from committing to technologies that may be incompatible with user needs based on user feedback. You free the team to select the technology that best solves the problem.Product pros can use market problems to understand the big picture while keeping tabs on the tiny details of user stories. Most important, by articulating problems and connecting them to small product increments, the team will deliver the most valuable, timely solutions to users.

]]>
Wed, 12 Apr 2017 00:00:00 -0400Getting a product to the market is hard. You might think that the hardest part is building the product itself, but I think the most challenging part is deciding what to build in the first place. Specifically, articulating what to build and why it’s important. For some product people, agile makes articulating requirements even harder. However, responding to change and breaking big things down into small things is exactly what we must do to deliver products the market will love as early as possible. And so I believe that agile is an opportunity to connect to the market, strengthen product requirements and get buy-in.

How do we accomplish this?

Listen to the market. Understand the problems, their pervasiveness and the context around these problems.

Turn that understanding into concise, relatively large problems and prioritize them.

Collaboratively break those problems down into user stories that the team can build.

Organize your problems and stories into a flexible problem-oriented roadmap that ideally targets specific personas with each release.

With each iteration big and small, funnel feedback into your roadmap as new problems or stories.

To start, get out of the office and engage with buyers and users in the marketplace. Interview them to find out what makes them tick, what keeps them up at night, what they read and who they follow. Pragmatic Marketing calls these NIHITO Visits (nothing important happens in the office). This activity will give you qualitative data that you can validate quantitatively through surveys and market analysis. Take these learnings and build personas, the representatives of your market.

Armed with market facts, you can now define the problem. Analyze your market data and personas, and look for patterns among them. These patterns will reveal market problems that are both urgent and pervasive. Write problem statements that describe the issue and include the emotional cost to the user and the frequency. Using your NIHITO visits, tally the number of times you have witnessed this problem in the market (be prepared to have examples in case you are challenged by stakeholders). Rate the business value of the market opportunity to your customers, and compare it to other problems you could solve.

At a previous company, we knew we needed to rebuild of our flagship product. Prior to development, we spent months interviewing potential and existing customers to discover the problems with our existing tool.

We discovered that it was a huge pain for our veteran users to use the wizard every time they set up a new job. We had thought the wizard would be a great way to ensure that users ticked all the boxes, but we failed to realize that it forced users to do things they didn’t need to do. We communicated the issue to the wider development team and collaboratively approached our user stories with this problem in mind. The result? We focused our user stories on keeping options open to the user, but not mandating them.

Getting feedback on working software is important in agile. We tested an early prototype on a small group of new and veteran users. We gave them a broad description of the goal and asked users to set up jobs. As we watched nervously, we learned that when we removed too much guidance from the process, both new and advanced users got lost. They enjoyed the open interface that allowed them to access the features that matter most to them, but whenever they set up new jobs, they didn’t know where to start or what to do next.

To strike a balance, we implemented a checklist that gently coached each user on what to do next without forcing them down a specific path. We implemented this into the next iteration; our focus group tested it and loved it.

So why didn’t I just tell development the solution I wanted built? Articulating problems rather than features frees engineers and designers to choose the right technology and design to solve the problem. Moreover, you have no idea if a feature is suitable for the market unless the users actually use it. Articulating problems rather than features avoids locking the team into technology that fails to achieve user goals. Placing the problem at the forefront keeps the organization focused on solving the user’s problem rather than the tools needed to do it.

Once you understand the problem’s frequency, business value and projected effort, you can prioritize market problems with the goal of solving the most urgent and pervasive ones first.

Organize the prioritized problems into releases that target each persona. Driven by urgency and market data, the teams will first build what matters most. This roadmap makes it easy for stakeholders (especially nontechnical ones) to understand who you are targeting, why and the order, all based on market facts. This also helps sales and marketing teams develop messaging that focuses on each persona.

Market problems are big and can’t be built in a single increment. So how can you be sure that your solution will solve the problem? A major goal in agile is to take big concepts and break them down into fully functioning product increments, then adjust the plan/product based on user feedback. In scrum methodology, you could apply market problems to epics. Epics are a collection of user stories that achieve a larger user goal. You can collaborate with design and development to break the market problem down into smaller user stories that contribute to solving the problem.

Typically, user stories are structured as mini problems: As [persona], I need to [what the user needs in their words] so that I can [the solution’s benefit]. Persona documents help guide the team to make the right decisions about the user’s needs and ensure they stay aligned to the market. Though it is a collaborative effort, you are responsible for getting the stories written, prioritized and understood.

For instance, a user story for the veteran users of the flagship product at my previous company might look like this: As Jen the IT analyst, I need to have a streamlined process that doesn’t ask unnecessary questions, so that I can set up new jobs without a lot of repetition. By attaching the persona to your user story, you provide context.

Most agile teams work to deliver a product in small increments called sprints (typically a one-to-three-week period). The design/development team commits to deliver a collection of stories that align with a sprint goal. This keeps the team focused on solving a specific set of small problems, resulting in working software that solves the overall goal for that sprint.

Since the team delivers fully functioning, tested product increments each sprint, you can now obtain user feedback on each product increment. Review the feedback with designers and developers. Better yet, have a designer and developer tag along to watch the user use it. Turn the feedback into new user stories. As you build the product, you may modify market problems or discover new ones. Remember, the roadmap must be flexible.

Are you beginning to see how everything connects? User stories are driven by the persona’s smallest need. A collection of user stories are built to meet a sprint goal. Multiple sprint goals combine into releases that are targeted to a specific persona. Single or multiple releases combine to solve the market’s problem.

It’s all driven by market data straight from the user. Iterating as you go, the product constantly evolves based on user feedback while still solving the primary problem. Articulating problems instead of specific technologies/features keeps the team from committing to technologies that may be incompatible with user needs based on user feedback. You free the team to select the technology that best solves the problem.Product pros can use market problems to understand the big picture while keeping tabs on the tiny details of user stories. Most important, by articulating problems and connecting them to small product increments, the team will deliver the most valuable, timely solutions to users.

]]>
tag:feedblitz.com,2017-04-12:36474/http://feeds.feedblitz.com/~/288529516/0/pragmaticmarketing/articles/requirements/6668204c2aa6e46ee4c489d11fee234bhttp://pragmaticmarketing.com/agility_articles/redirect?id=20564http://feeds.feedblitz.com/~/226005202/0/pragmaticmarketing/articles/requirements~Job-Hunting-is-Product-ManagementMine is a common story, but you don’t hear it told very often. My startup failed.

I started a company based on a technology idea. I raised a bunch of money. I put together a team of passionate, talented people. We built a product. We went to market. Everything went well, until—pretty dramatically—it didn’t.

The company that I spent four years building simply evaporated. I found myself with no income, no savings, a young baby at home, and—you guessed it—no job. What did I do? Did I cry? Did I complain? Yes. I did both.

But after I did those things, I set myself up to find a job. It took me a while, and it was brutal, but it is that journey—from failed startup founder to gainfully employed product manager—that I would like to recount for you. Job hunting can be hard, and I want to share my hard-won findings with others who can use them. Also, I want to show how the tools that I picked up as a product lead helped me navigate some rough personal waters.

Who Would Hire Me Now?

My story starts the first day after I threw in the towel on my company. You can imagine the stress. How would I find my feet? What job could I do? Who would hire me now? I had no idea where to start. Out of instinct, I resorted to the kind of product thinking I had spent four years practicing. The job hunt, I figured, was essentially an exercise in finding product/market fit. I was the product and I was looking to fit somewhere. Instead of thinking too much about the daunting task ahead of me, I simply put my head down, got out my spreadsheets and started tracking the metrics.

I set up my sales funnel and initiated the process of finding a winning strategy. I would focus on each step of the job-hunting process in order: application, first-round interview, second-round interview and final interview.

The only job I really wanted was a product manager role, but keep in mind, my confidence was shot. I had just taken a great idea and a great team and flown them into the side of a mountain. I was devastated and limping through the legal and tax wreckage. I didn’t feel lucky. I didn’t want to set my sights too high because I didn’t feel like I could afford to fail. So, in order to mitigate my chances of not getting my goal position, I decided to go after two other positions as well: producer and project manager. I started with a kind of “spray and pray” strategy, hoping that if I hit up enough people, something would stick.

Looking back, that lack of focus turned out to be a wasteful mistake. But I’ll come back to that.

Now that I knew what I was applying for, I needed to figure out the best strategy to use on my application. For example, what was the best way to put together a resume? Everyone will tell you that a resume is a thing you craft after you decide which job to apply for. They will say that the raw material of your experience needs to be shaped to match each position. But is that true?

Further, what’s the best strategy for a cover letter? Those same people will also say you must tailor your cover letter to match each individual company, position and hiring manager to which you apply. They will say that only a considered, well-researched cover letter will win you a first-round interview. But again, is that actually true?

Do people actually read cover letters these days? The cover letter is a digital document, as ephemeral and ignorable as any email. I knew from experience that, as a busy team member in a fast-paced company, reading more than a couple of sentences of any missive was rare. When it did happen, it was for a specific bottom-line reason, like a contract, competitive research or technology deep-dive. Someone who wanted something from me rarely got more than a brief look at the subject line.

Test Various Methods and Track Their Efficacy

I wanted answers to these questions. I didn’t want to waste my time following bad advice derived from someone else’s experience or pursuing strategies that didn’t fit my situation. The only way to discover the strategy that would work best for me was to test various methods and track their efficacy. I wrote custom letters and custom resumes. I sent general letters and general resumes. I tried various degrees of each, labeling each effort and waiting to hear if I got an interview.

After applying for more than 40 jobs over a month, I had enough data to make a solid strategy decision. It turned out that volume was more effective than precision. By using a template resume and letter, I won a first-round interview 15 percent of the time, and I could crank out five applications a day. If I wrote a customized cover letter and tailored my resume to the job, I would win a first-round interview slightly more often, 25 percent of the time, but it would take me one full day per application. So, in practice, a general application won an interview every one-and-a-half days, whereas a custom application took four.

It took 40 tries to figure out, but this measurement process gave me a sense of control. If I got discouraged, I would just look at the numbers and reassure myself that it was working. Most important, this data let me be confident in my strategy for the first step in the funnel. Now I could focus my attention on the second step: the screening interview.

I didn’t realize it at first, but I was bombing my first-round interviews. You never know you’re bombing an interview during the interview itself because the person you talk to is always super nice. But after more than five strikeouts, I needed some objective feedback. I enlisted friends to walk me through a typical screening-interview scenario and take notes on whether they would hire me. Right away, they were able to give me good strategic advice.

Wear Your Failures as a Badge of Honor

I was talking in an apologetic tone about the parts of my personal history that didn’t conform perfectly to the job description. The fact that my startup failed, for example, was something I wasn’t proud of, and that came through in the way I talked about it. My friends’ feedback was to “own” my failures, to turn them into the scars from a war that I should be proud to have served in. It’s true, isn’t it? You can’t have lost if you didn’t at least play the game.

Listen to What They Want You to Say

It seems I wasn’t listening enough. This is a common and understandable mistake for a job seeker. I mean, the pressure is pretty high. You’re unemployed. It’s not like you’ve got all year to find that perfect snuggly little job. You gots to work! I wasn’t paying attention to the clues the interviewer was giving me. The truth is, that first-round interviewer wants to like you. In fact, they are often telling you exactly what they want you to say. A great example is a leading question like, “What kind of people- management responsibilities did you have at your previous position?” You can assume that the interviewer is looking for an applicant with experience managing people. The answer to that question is not, “Well, I did manage people but I really liked getting out of the building and selling.”

This was probably the single best piece of advice I got during my job hunt. A friend helped me build a little resource of stories that I could rehearse and use during interviews. I put one together around teamwork, one about learning from my mistakes, one about closing a big deal and one about my professional aspirations. Then, in the interview itself, I could repurpose these stories to great effect.

And it worked. With these three strategies (speaking proudly about my past, listening closely to the interviewer and using my cadre of stories), I went through to the second round on nearly every interview. I only failed to advance if an interviewer misjudged my experience, interviewing me because they hoped I was less—or more—experienced than I was.

Perfect. I was moving down the funnel and identifying the winning strategy at each stage. Next was the second-round interview and I was on a roll.

I quickly realized, however, that the second-round interview was a totally different animal. It was most often with someone I would work with if I got the job. They had a more precise idea of the skills, attitude and style they were looking for. Their questions about my experience were far more probing. They would ask me to detail exactly what I did every day at my startup, or what decisions I made that I regretted or how I got along with my co-workers. Also, they were finely tuned to my tone. I could sense they were looking harder for red flags than that first screener. The pressure was high and I have to be honest. I blinked.

Find Real Fit

It was in this second round that I let myself get swept up in the heat of the moment and made my biggest error. I let myself stretch the truth.

I was two months into my job search. I was temping at a publishing firm in Manhattan. As everyone knows, temping does not a living wage pay, and I was getting increasingly desperate for a real job. I had applied to an advertising agency for a producer position and in the second-round interview, I was asked if I had advertising experience. The truth was “no.” I had never worked for an ad agency. My only experience in advertising was as a startup founder who was trying to redefine advertising for online video. Looking back, it was partly my lack of advertising experience that contributed to my startup not hitting its mark. But, I blustered on that question and spun a story about closing a deal with a major broadcaster. Unfortunately, the interviewer bought it.

Perhaps the interviewer was as desperate to hire someone as I was to find a job. Perhaps, they didn’t really think through their own job requirements before interviewing me but, together, we pushed past that glaring hole in my skill set and I moved forward in the process. In fact, I got the job. The final interview was essentially a repeat of my second-round interview. I presented myself as sane and capable, and when it came time to ask about my actual advertising experience, I blustered though with my same story, selling myself on energy and willingness to learn rather than knowing what I was talking about.

I’ll skip over the gruesome details, but it turned into a horrible mess. That little fudge on the details of my experience cost me dearly. I was in over my head on the very first day. They let me flail around for six weeks, watching me make super junior mistakes, and then they finally let me go. It was perhaps the worst experience of my life. I’m not exaggerating. The combined stress of having a 6-month-old baby, falling behind on my bills and watching the guillotine blade being slowly raised above my head was very nearly the end of me.

You must find real fit. Be honest with yourself and others. Cramming your round product into a square hole will just waste resources. It doesn’t work. You cannot fudge fit. Both the best and worst thing about data-driven decision-making is that it’s clear. The product either sings or it doesn’t. You cannot fake the data in your favor. Think about your own experience. Surely there have been times when you tried to make something fit that clearly didn’t. It could have been a relationship, or a new friendship or even a new home. You thought perhaps you could adapt to it. You thought perhaps if you forced it hard enough it would eventually feel comfortable. Did it work? I didn’t think so.

The same is true in job hunting. Just because someone offers you a job does not mean it’s the right job for you. It is just as much your responsibility to pay attention to the fit as it is for the hiring manager. You know you best. They know their company best. Together, you must make sure these two things will work well together. It’s hard. I get that. As a job seeker, the pressure is on you. You want to get a job fast and it doesn’t feel, in the moment, like you have the luxury to be choosy. Let my tale disabuse you of that misconception now … please.

It Wasn’t About Me, It Was About the Detailed Work of Driving Traction

Boom. I found myself back at square one, even more broke and more stressed. Boy, was that an interesting time.

What I will say, however, is that being able to look at my job hunt spreadsheet and review my strategic findings from my last push was heartening. Just being able to inject that little bit of objectivity into the process, where it wasn’t about what a failure I was or what I did wrong or the long list of my deficiencies. It was just about following the metrics. It made me feel confident that there was a place for me, for the product I was peddling. All I had to do was pay attention to where my product was engaging customers and how to facilitate greater engagement.

Metrics-wise, this second effort was greatly improved. With more focused targeting, I was getting first-round interviews 50 percent of the time and moving through to second-round interviews. Then, in these second-round interviews, I took pains to be up front about what I was good at and the experience I had. I asked questions to get a sense of what the job would entail and dug into the requirements. This attention to fit did not go unnoticed with hiring managers. I didn’t move forward with every company, but when I did, I felt confident. There was no tension between what the job entailed and my skill set. It was a job I knew I could do, at a salary I was willing to take, and it took me only three final interviews to find and be offered a solid position at my current company.

Happy ending? Yes. Definitely. But the journey to get there was harrowing. I shudder to think where I could have ended up had I not used the product management tools of funnel analysis, product/market fit, user interviews and iteration. I’m sure without these helpful tools I would have given up much sooner. I would probably be in some less-than-happy situation, providing a lot less value to my employer.

Job hunting is not easy, and the temptation is to go for the quickest win, but let my story be a vote for data-driven decision-making. Let my story be a strong first-person example of the value of paying attention to the funnel, of working hard to find the right job fit, of using your instincts, but also taking strength from the numbers. Let my story prove that job hunting IS product management.

]]>
Tue, 08 Nov 2016 00:00:00 -0400Mine is a common story, but you don’t hear it told very often. My startup failed.

I started a company based on a technology idea. I raised a bunch of money. I put together a team of passionate, talented people. We built a product. We went to market. Everything went well, until—pretty dramatically—it didn’t.

The company that I spent four years building simply evaporated. I found myself with no income, no savings, a young baby at home, and—you guessed it—no job. What did I do? Did I cry? Did I complain? Yes. I did both.

But after I did those things, I set myself up to find a job. It took me a while, and it was brutal, but it is that journey—from failed startup founder to gainfully employed product manager—that I would like to recount for you. Job hunting can be hard, and I want to share my hard-won findings with others who can use them. Also, I want to show how the tools that I picked up as a product lead helped me navigate some rough personal waters.

Who Would Hire Me Now?

My story starts the first day after I threw in the towel on my company. You can imagine the stress. How would I find my feet? What job could I do? Who would hire me now? I had no idea where to start. Out of instinct, I resorted to the kind of product thinking I had spent four years practicing. The job hunt, I figured, was essentially an exercise in finding product/market fit. I was the product and I was looking to fit somewhere. Instead of thinking too much about the daunting task ahead of me, I simply put my head down, got out my spreadsheets and started tracking the metrics.

I set up my sales funnel and initiated the process of finding a winning strategy. I would focus on each step of the job-hunting process in order: application, first-round interview, second-round interview and final interview.

The only job I really wanted was a product manager role, but keep in mind, my confidence was shot. I had just taken a great idea and a great team and flown them into the side of a mountain. I was devastated and limping through the legal and tax wreckage. I didn’t feel lucky. I didn’t want to set my sights too high because I didn’t feel like I could afford to fail. So, in order to mitigate my chances of not getting my goal position, I decided to go after two other positions as well: producer and project manager. I started with a kind of “spray and pray” strategy, hoping that if I hit up enough people, something would stick.

Looking back, that lack of focus turned out to be a wasteful mistake. But I’ll come back to that.

Now that I knew what I was applying for, I needed to figure out the best strategy to use on my application. For example, what was the best way to put together a resume? Everyone will tell you that a resume is a thing you craft after you decide which job to apply for. They will say that the raw material of your experience needs to be shaped to match each position. But is that true?

Further, what’s the best strategy for a cover letter? Those same people will also say you must tailor your cover letter to match each individual company, position and hiring manager to which you apply. They will say that only a considered, well-researched cover letter will win you a first-round interview. But again, is that actually true?

Do people actually read cover letters these days? The cover letter is a digital document, as ephemeral and ignorable as any email. I knew from experience that, as a busy team member in a fast-paced company, reading more than a couple of sentences of any missive was rare. When it did happen, it was for a specific bottom-line reason, like a contract, competitive research or technology deep-dive. Someone who wanted something from me rarely got more than a brief look at the subject line.

Test Various Methods and Track Their Efficacy

I wanted answers to these questions. I didn’t want to waste my time following bad advice derived from someone else’s experience or pursuing strategies that didn’t fit my situation. The only way to discover the strategy that would work best for me was to test various methods and track their efficacy. I wrote custom letters and custom resumes. I sent general letters and general resumes. I tried various degrees of each, labeling each effort and waiting to hear if I got an interview.

After applying for more than 40 jobs over a month, I had enough data to make a solid strategy decision. It turned out that volume was more effective than precision. By using a template resume and letter, I won a first-round interview 15 percent of the time, and I could crank out five applications a day. If I wrote a customized cover letter and tailored my resume to the job, I would win a first-round interview slightly more often, 25 percent of the time, but it would take me one full day per application. So, in practice, a general application won an interview every one-and-a-half days, whereas a custom application took four.

It took 40 tries to figure out, but this measurement process gave me a sense of control. If I got discouraged, I would just look at the numbers and reassure myself that it was working. Most important, this data let me be confident in my strategy for the first step in the funnel. Now I could focus my attention on the second step: the screening interview.

I didn’t realize it at first, but I was bombing my first-round interviews. You never know you’re bombing an interview during the interview itself because the person you talk to is always super nice. But after more than five strikeouts, I needed some objective feedback. I enlisted friends to walk me through a typical screening-interview scenario and take notes on whether they would hire me. Right away, they were able to give me good strategic advice.

Wear Your Failures as a Badge of Honor

I was talking in an apologetic tone about the parts of my personal history that didn’t conform perfectly to the job description. The fact that my startup failed, for example, was something I wasn’t proud of, and that came through in the way I talked about it. My friends’ feedback was to “own” my failures, to turn them into the scars from a war that I should be proud to have served in. It’s true, isn’t it? You can’t have lost if you didn’t at least play the game.

Listen to What They Want You to Say

It seems I wasn’t listening enough. This is a common and understandable mistake for a job seeker. I mean, the pressure is pretty high. You’re unemployed. It’s not like you’ve got all year to find that perfect snuggly little job. You gots to work! I wasn’t paying attention to the clues the interviewer was giving me. The truth is, that first-round interviewer wants to like you. In fact, they are often telling you exactly what they want you to say. A great example is a leading question like, “What kind of people- management responsibilities did you have at your previous position?” You can assume that the interviewer is looking for an applicant with experience managing people. The answer to that question is not, “Well, I did manage people but I really liked getting out of the building and selling.”

This was probably the single best piece of advice I got during my job hunt. A friend helped me build a little resource of stories that I could rehearse and use during interviews. I put one together around teamwork, one about learning from my mistakes, one about closing a big deal and one about my professional aspirations. Then, in the interview itself, I could repurpose these stories to great effect.

And it worked. With these three strategies (speaking proudly about my past, listening closely to the interviewer and using my cadre of stories), I went through to the second round on nearly every interview. I only failed to advance if an interviewer misjudged my experience, interviewing me because they hoped I was less—or more—experienced than I was.

Perfect. I was moving down the funnel and identifying the winning strategy at each stage. Next was the second-round interview and I was on a roll.

I quickly realized, however, that the second-round interview was a totally different animal. It was most often with someone I would work with if I got the job. They had a more precise idea of the skills, attitude and style they were looking for. Their questions about my experience were far more probing. They would ask me to detail exactly what I did every day at my startup, or what decisions I made that I regretted or how I got along with my co-workers. Also, they were finely tuned to my tone. I could sense they were looking harder for red flags than that first screener. The pressure was high and I have to be honest. I blinked.

Find Real Fit

It was in this second round that I let myself get swept up in the heat of the moment and made my biggest error. I let myself stretch the truth.

I was two months into my job search. I was temping at a publishing firm in Manhattan. As everyone knows, temping does not a living wage pay, and I was getting increasingly desperate for a real job. I had applied to an advertising agency for a producer position and in the second-round interview, I was asked if I had advertising experience. The truth was “no.” I had never worked for an ad agency. My only experience in advertising was as a startup founder who was trying to redefine advertising for online video. Looking back, it was partly my lack of advertising experience that contributed to my startup not hitting its mark. But, I blustered on that question and spun a story about closing a deal with a major broadcaster. Unfortunately, the interviewer bought it.

Perhaps the interviewer was as desperate to hire someone as I was to find a job. Perhaps, they didn’t really think through their own job requirements before interviewing me but, together, we pushed past that glaring hole in my skill set and I moved forward in the process. In fact, I got the job. The final interview was essentially a repeat of my second-round interview. I presented myself as sane and capable, and when it came time to ask about my actual advertising experience, I blustered though with my same story, selling myself on energy and willingness to learn rather than knowing what I was talking about.

I’ll skip over the gruesome details, but it turned into a horrible mess. That little fudge on the details of my experience cost me dearly. I was in over my head on the very first day. They let me flail around for six weeks, watching me make super junior mistakes, and then they finally let me go. It was perhaps the worst experience of my life. I’m not exaggerating. The combined stress of having a 6-month-old baby, falling behind on my bills and watching the guillotine blade being slowly raised above my head was very nearly the end of me.

You must find real fit. Be honest with yourself and others. Cramming your round product into a square hole will just waste resources. It doesn’t work. You cannot fudge fit. Both the best and worst thing about data-driven decision-making is that it’s clear. The product either sings or it doesn’t. You cannot fake the data in your favor. Think about your own experience. Surely there have been times when you tried to make something fit that clearly didn’t. It could have been a relationship, or a new friendship or even a new home. You thought perhaps you could adapt to it. You thought perhaps if you forced it hard enough it would eventually feel comfortable. Did it work? I didn’t think so.

The same is true in job hunting. Just because someone offers you a job does not mean it’s the right job for you. It is just as much your responsibility to pay attention to the fit as it is for the hiring manager. You know you best. They know their company best. Together, you must make sure these two things will work well together. It’s hard. I get that. As a job seeker, the pressure is on you. You want to get a job fast and it doesn’t feel, in the moment, like you have the luxury to be choosy. Let my tale disabuse you of that misconception now … please.

It Wasn’t About Me, It Was About the Detailed Work of Driving Traction

Boom. I found myself back at square one, even more broke and more stressed. Boy, was that an interesting time.

What I will say, however, is that being able to look at my job hunt spreadsheet and review my strategic findings from my last push was heartening. Just being able to inject that little bit of objectivity into the process, where it wasn’t about what a failure I was or what I did wrong or the long list of my deficiencies. It was just about following the metrics. It made me feel confident that there was a place for me, for the product I was peddling. All I had to do was pay attention to where my product was engaging customers and how to facilitate greater engagement.

Metrics-wise, this second effort was greatly improved. With more focused targeting, I was getting first-round interviews 50 percent of the time and moving through to second-round interviews. Then, in these second-round interviews, I took pains to be up front about what I was good at and the experience I had. I asked questions to get a sense of what the job would entail and dug into the requirements. This attention to fit did not go unnoticed with hiring managers. I didn’t move forward with every company, but when I did, I felt confident. There was no tension between what the job entailed and my skill set. It was a job I knew I could do, at a salary I was willing to take, and it took me only three final interviews to find and be offered a solid position at my current company.

Happy ending? Yes. Definitely. But the journey to get there was harrowing. I shudder to think where I could have ended up had I not used the product management tools of funnel analysis, product/market fit, user interviews and iteration. I’m sure without these helpful tools I would have given up much sooner. I would probably be in some less-than-happy situation, providing a lot less value to my employer.

Job hunting is not easy, and the temptation is to go for the quickest win, but let my story be a vote for data-driven decision-making. Let my story be a strong first-person example of the value of paying attention to the funnel, of working hard to find the right job fit, of using your instincts, but also taking strength from the numbers. Let my story prove that job hunting IS product management.

]]>
tag:feedblitz.com,2016-11-08:36474/http://feeds.feedblitz.com/~/226005202/0/pragmaticmarketing/articles/requirements/f6e66d1af5425cbf12ff9a73cb56b9a1http://pragmaticmarketing.com/agility_articles/redirect?id=20559http://feeds.feedblitz.com/~/226012328/0/pragmaticmarketing/articles/requirements~What-is-a-Customer-NeedThe drinking fountain is a fixture in most public buildings. Chances are, the one in your office hallway is indistinguishable from the one you encountered on your first day of kindergarten. You probably haven’t thought much about drinking fountains since then, unless you are a plumber or work at Elkay Manufacturing.

In 2010, Elkay, a Chicago-based maker of sinks, faucets and other fixtures, launched its EZH20 drinking fountain and bottle-filler, revolutionizing what had been a mature, stable market. By studying drinking fountains—the people who use them, where people use them, and most important, what people use them for—the company found a huge opportunity to solve a market problem by developing a breakthrough new fountain.

The new fountain provides not only a refreshing sip of water, but also an easy way to fill the reusable water bottles many consumers carry. As a private company, Elkay does not disclose sales, but its new fixtures can be found nearly everywhere: college dormitories, airports, hospitals, office buildings and shopping malls. In short, it’s a winner.

Elkay’s case demonstrates what product developers and marketers know to be fundamental: Successful innovations must solve market problems. Yet before you can create a great solution to solve that market problem, you must first understand the customer need, and define them in clear, unambiguous language. After all, how can you understand something you cannot define?

To start, what is a customer need (or what Pragmatic Marketing calls a market problem)? If your response is somewhere between a blank stare and a headache, you are not alone. Many hands-on innovators—product professionals, market researchers, engineers, marketing managers—still cannot agree on what defines a need. It is not for lack of discussion. Articles, conference presentations and blog posts have tried to define or differentiate flavors of customer needs, using terms like: wants, benefits, preferences, motivations, requirements, attitudes, functional goals, desired outcomes, product attributes, critical-to-quality characteristics, jobs-to-be-done, problems and use cases. This proliferation in terminology can leave innovators confused, wondering where to start.

Rather than arguing over the right term, I prefer to stick with the most familiar one—customer needs—and define it well. Some use this definition: A need is a desire that causes a customer to buy a product. If customers buy products to satisfy needs, then needs provoke customers to buy products. But this definition is vague; it doesn’t give any direction to product teams or market researchers on how to understand what customers want.

Instead, let us consider a more useful definition: A need is an opportunity to deliver a benefit to a customer. This definition contains three components:

1. A benefit that has value (the what)2. A customer who values the benefit (the who)3. A context that creates the opportunity to deliver the benefit (the when or where)

The Benefit

The first component is the what, a benefit that has value. A benefit could be tangible or functional. Perhaps it helps a person do something faster, easier or more accurately. It could be intangible or emotional, helping a person feel better or avoid feeling worse.

Successful products deliver some combination of functional and emotional benefits. The mix varies by category. Some industrial products deliver almost entirely functional benefits, while some consumer products deliver entirely emotional benefits. We must assess the opportunity to deliver both functional and emotional benefits, no matter which market we are in.

For example, the programmable thermostat is a common product. Its main product features are clear: It automatically controls your home’s heating and cooling system throughout the day, using a built-in clock and microprocessor. Some models offer variable programs for weekends and weekdays or for each day of the week. Others have lighted displays and touchscreen controls. The newest models use the internet to remotely connect to smartphone apps.

These features are merely components of a solution, and a solution without a problem has no value. The features in your programmable thermostat deliver functional benefits like ensuring your home is a comfortable temperature when you arrive from work, preventing frozen pipes during cold days, regulating how much energy you consume and reducing system wear from excessive cycling on and off. They deliver emotional benefits such as helping you feel like a smart homeowner, perceiving yourself as environmentally responsible and signaling your environmental commitment to guests. You did not buy a programmable thermostat because it had a lighted screen; you bought it so that you could turn up the heat on a dark, cold night without turning on the lights and waking the infant you just spent an hour putting to bed.

The Customer

The second lens is the who, the customer who desires the benefit and is willing to exchange something valuable like money or information. A good understanding of needs means identifying and understanding the right customers.

Sometimes, the customer is simple to spot. If you sell a consumer product, your customer is the end consumer, the primary shopper who purchases the product. However, if you sell to a business, your customer is often a combination of several individuals who may seek one or more different benefits from your product, or your competitors’ products, and they must reach a consensus on what to buy.

Not all customers perceive equal value in a benefit. A hospital purchasing manager may not see much benefit in a premium lightbulb with a lifespan 20 times longer than a traditional bulb. However, a maintenance manager, whose budget pays union wages to the workers changing lightbulbs every day, may value the same benefit much more. Similarly, demographics, firmographics, behaviors and attitudes also vary by customer. Male consumers may differ from female consumers. Managers at small businesses differ from those at large businesses. And while one investor may be comfortable with a large amount of risk and volatility, another may prefer security and stability. Even two otherwise similar individuals may hold different opinions.

The Context

The third and final component of a need is the context, the when or where that a customer desires a benefit. Needs are never spontaneous; they are situational. A benefit only has value if it solves a problem for a customer at a given time or in a given place. Common contexts include: a physical place or setting such as at work, at home or in the car; an occasion, such as a dinner date or business meal; a daypart, such as morning, afternoon or evening; or even a life stage, such as getting an education, raising children or preparing to retire. Context helps us explain why a benefit has customer value and how that value may change as the context changes.

Of course, not every context is relevant to every product category. As you might imagine, daypart or occasion contexts are more relevant to a foodservice or entertainment business, while life-stage contexts are more relevant to a financial-services business. In addition, contexts are rarely static, and customers regularly move across them. A business executive flying today for a meeting may be on the same plane next week for her family vacation. And she may be saving for her retirement at the same time she is saving to finance her children’s education. She may have dinner with her husband tonight but eat with a client at another restaurant tomorrow. In each case, she values the delivered benefits differently.

Getting Better at Uncovering Customer Needs

Recognizing the three components of a customer need lies at the heart of a solid understanding of the voice of the customer. Applying them will help you better structure your efforts to gain customer insight by posing relevant questions to relevant people about relevant situations. Here are three ways to get started:

Do not conflate the solutions customers say they want with the underlying benefits those solutions deliver. Too many product teams think that listening to the voice of the customer simply means asking customers to specify—or even invent—the right solution to a given problem, despite considerable evidence that most customers are not particularly creative. Instead, as a first step toward solving the problem in a new and different way, product teams should strive to understand why customers have those problems.

Accomplishing this goal requires you to change how you interact with customers as you design new products. Rather than asking customers which features should be in your solution, reorient the conversation to explore the problems customers confront every day, and the benefits they would realize by solving those problems. Encourage customers to provide examples and stories to illustrate their problems. Even better, get out in the field and watch them confront those problems face-to-face to understand the functional and emotional benefits they desire most.

Broaden your view of the customers you study. B2C marketers must consider different attitudinal, behavioral or demographic customer profiles. B2B marketers must consider different customer roles within different kinds of companies. Instead of asking, “Who is the customer?” product managers should ask, “Who are the customers?” An intentional approach to customer sampling is vital to any voice of the customer initiative.

In addition to considering all plausible customer segments along the length of your value chain, it is essential to include customers who may have abandoned you for competitors. And consider as customers those who left the market entirely and no longer purchase from anyone: Why did they leave? Also, try to include customers who have yet to enter the market because they find the existing solutions too complex, expensive or inaccessible. Often, the most valuable insights that lead to the most disruptive innovations come from customers who are not buying from anyone, because nothing delivers the right benefit at an acceptable price.

Study different customer contexts and understand how they are different. It is impossible to understand the value of a benefit without first understanding where or when that benefit is desired, and how—if at all—customers benefit. Studying context will help identify constraints that rule out some solutions and the enablers that complement others.

Remember, simply because customers desire a benefit in one setting does not mean that they will desire it in another. Nor does it mean that the solution to a customer problem will work equally well in all contexts.

Consider all contexts as potentially different, potentially relevant sources of new information. Then use projective, experience-based interviewing, observational research, customer journey mapping and other deep-insight voice ofthe customer methods to be sure you examine a problem from all perspectives.

As the story of Elkay’s revolutionary drinking fountain demonstrates, successful new products are rarely the outcome of pure inspiration. Instead, they occur because of a diligent, intentional strategy. Companies that make the voice of the customer the foundation of their innovation system—understanding who needs what, where and when, at the front end of new product development—launch better products that achieve success in the market.

When you reflect on your next step in becoming a better innovator, first consider whether you truly understand what a customer need means, what problems they are fixing. That way you will know what to look for the next time you study your customers, and you will be better positioned to create a solution that delivers value to them and to your company.

Identify the Right Customers

In B2B markets, the “customer” represents a collection of several stakeholders. A single person rarely buys and uses your product. Even when that’s the case, they are rarely the consumer and often have to satisfy downstream customers of their own.

Satisfying the customer really means satisfying many customers. This additional complexity can make it difficult to understand which customers’ needs are most relevant, and, consequently, where to deploy your limited resources for gathering the voice of the customer.

We recommend two best practices for homing in on the right customers to study. First, map your value chain. Beginning with your ultimate end user, trace a path back to the point at which your finished product leaves your company’s control, noting each link in the chain where the product changes hands until the end consumer has it. Each link can be considered a customer. Then ask yourself how likely it is that each customer can provide relevant information to influence product design. Use a broad perspective. For example, one of the biggest innovations in soft drinks, Coca-Cola’s Fridge Pack format, was conceived by aluminum giant Alcoa from insights identified in consumer shop-along research.

Second, within each link in the chain, map all the stakeholders to consider who may have relevant information for your product. We have found that stakeholders for any B2B product tend to play a generic set of roles, regardless of category.

Typically, there is:

• A specifier who designs the application• An installer who sets up the product• An operator who uses the product• A maintainer who fixes the product when it breaks• A purchaser who negotiates for and orders the product• An economic buyer whose budget pays for the product

Sometimes the same person plays more than one role, and other times not all roles are present with each customer. However, unless you consider whether these roles exist and how they influence your market, you risk overlooking an important constituency whose opinion may make or break your product.

]]>
Tue, 08 Nov 2016 00:00:00 -0400The drinking fountain is a fixture in most public buildings. Chances are, the one in your office hallway is indistinguishable from the one you encountered on your first day of kindergarten. You probably haven’t thought much about drinking fountains since then, unless you are a plumber or work at Elkay Manufacturing.

In 2010, Elkay, a Chicago-based maker of sinks, faucets and other fixtures, launched its EZH20 drinking fountain and bottle-filler, revolutionizing what had been a mature, stable market. By studying drinking fountains—the people who use them, where people use them, and most important, what people use them for—the company found a huge opportunity to solve a market problem by developing a breakthrough new fountain.

The new fountain provides not only a refreshing sip of water, but also an easy way to fill the reusable water bottles many consumers carry. As a private company, Elkay does not disclose sales, but its new fixtures can be found nearly everywhere: college dormitories, airports, hospitals, office buildings and shopping malls. In short, it’s a winner.

Elkay’s case demonstrates what product developers and marketers know to be fundamental: Successful innovations must solve market problems. Yet before you can create a great solution to solve that market problem, you must first understand the customer need, and define them in clear, unambiguous language. After all, how can you understand something you cannot define?

To start, what is a customer need (or what Pragmatic Marketing calls a market problem)? If your response is somewhere between a blank stare and a headache, you are not alone. Many hands-on innovators—product professionals, market researchers, engineers, marketing managers—still cannot agree on what defines a need. It is not for lack of discussion. Articles, conference presentations and blog posts have tried to define or differentiate flavors of customer needs, using terms like: wants, benefits, preferences, motivations, requirements, attitudes, functional goals, desired outcomes, product attributes, critical-to-quality characteristics, jobs-to-be-done, problems and use cases. This proliferation in terminology can leave innovators confused, wondering where to start.

Rather than arguing over the right term, I prefer to stick with the most familiar one—customer needs—and define it well. Some use this definition: A need is a desire that causes a customer to buy a product. If customers buy products to satisfy needs, then needs provoke customers to buy products. But this definition is vague; it doesn’t give any direction to product teams or market researchers on how to understand what customers want.

Instead, let us consider a more useful definition: A need is an opportunity to deliver a benefit to a customer. This definition contains three components:

1. A benefit that has value (the what)
2. A customer who values the benefit (the who)
3. A context that creates the opportunity to deliver the benefit (the when or where)

The Benefit

The first component is the what, a benefit that has value. A benefit could be tangible or functional. Perhaps it helps a person do something faster, easier or more accurately. It could be intangible or emotional, helping a person feel better or avoid feeling worse.

Successful products deliver some combination of functional and emotional benefits. The mix varies by category. Some industrial products deliver almost entirely functional benefits, while some consumer products deliver entirely emotional benefits. We must assess the opportunity to deliver both functional and emotional benefits, no matter which market we are in.

For example, the programmable thermostat is a common product. Its main product features are clear: It automatically controls your home’s heating and cooling system throughout the day, using a built-in clock and microprocessor. Some models offer variable programs for weekends and weekdays or for each day of the week. Others have lighted displays and touchscreen controls. The newest models use the internet to remotely connect to smartphone apps.

These features are merely components of a solution, and a solution without a problem has no value. The features in your programmable thermostat deliver functional benefits like ensuring your home is a comfortable temperature when you arrive from work, preventing frozen pipes during cold days, regulating how much energy you consume and reducing system wear from excessive cycling on and off. They deliver emotional benefits such as helping you feel like a smart homeowner, perceiving yourself as environmentally responsible and signaling your environmental commitment to guests. You did not buy a programmable thermostat because it had a lighted screen; you bought it so that you could turn up the heat on a dark, cold night without turning on the lights and waking the infant you just spent an hour putting to bed.

The Customer

The second lens is the who, the customer who desires the benefit and is willing to exchange something valuable like money or information. A good understanding of needs means identifying and understanding the right customers.

Sometimes, the customer is simple to spot. If you sell a consumer product, your customer is the end consumer, the primary shopper who purchases the product. However, if you sell to a business, your customer is often a combination of several individuals who may seek one or more different benefits from your product, or your competitors’ products, and they must reach a consensus on what to buy.

Not all customers perceive equal value in a benefit. A hospital purchasing manager may not see much benefit in a premium lightbulb with a lifespan 20 times longer than a traditional bulb. However, a maintenance manager, whose budget pays union wages to the workers changing lightbulbs every day, may value the same benefit much more. Similarly, demographics, firmographics, behaviors and attitudes also vary by customer. Male consumers may differ from female consumers. Managers at small businesses differ from those at large businesses. And while one investor may be comfortable with a large amount of risk and volatility, another may prefer security and stability. Even two otherwise similar individuals may hold different opinions.

The Context

The third and final component of a need is the context, the when or where that a customer desires a benefit. Needs are never spontaneous; they are situational. A benefit only has value if it solves a problem for a customer at a given time or in a given place. Common contexts include: a physical place or setting such as at work, at home or in the car; an occasion, such as a dinner date or business meal; a daypart, such as morning, afternoon or evening; or even a life stage, such as getting an education, raising children or preparing to retire. Context helps us explain why a benefit has customer value and how that value may change as the context changes.

Of course, not every context is relevant to every product category. As you might imagine, daypart or occasion contexts are more relevant to a foodservice or entertainment business, while life-stage contexts are more relevant to a financial-services business. In addition, contexts are rarely static, and customers regularly move across them. A business executive flying today for a meeting may be on the same plane next week for her family vacation. And she may be saving for her retirement at the same time she is saving to finance her children’s education. She may have dinner with her husband tonight but eat with a client at another restaurant tomorrow. In each case, she values the delivered benefits differently.

Getting Better at Uncovering Customer Needs

Recognizing the three components of a customer need lies at the heart of a solid understanding of the voice of the customer. Applying them will help you better structure your efforts to gain customer insight by posing relevant questions to relevant people about relevant situations. Here are three ways to get started:

Do not conflate the solutions customers say they want with the underlying benefits those solutions deliver. Too many product teams think that listening to the voice of the customer simply means asking customers to specify—or even invent—the right solution to a given problem, despite considerable evidence that most customers are not particularly creative. Instead, as a first step toward solving the problem in a new and different way, product teams should strive to understand why customers have those problems.

Accomplishing this goal requires you to change how you interact with customers as you design new products. Rather than asking customers which features should be in your solution, reorient the conversation to explore the problems customers confront every day, and the benefits they would realize by solving those problems. Encourage customers to provide examples and stories to illustrate their problems. Even better, get out in the field and watch them confront those problems face-to-face to understand the functional and emotional benefits they desire most.

Broaden your view of the customers you study. B2C marketers must consider different attitudinal, behavioral or demographic customer profiles. B2B marketers must consider different customer roles within different kinds of companies. Instead of asking, “Who is the customer?” product managers should ask, “Who are the customers?” An intentional approach to customer sampling is vital to any voice of the customer initiative.

In addition to considering all plausible customer segments along the length of your value chain, it is essential to include customers who may have abandoned you for competitors. And consider as customers those who left the market entirely and no longer purchase from anyone: Why did they leave? Also, try to include customers who have yet to enter the market because they find the existing solutions too complex, expensive or inaccessible. Often, the most valuable insights that lead to the most disruptive innovations come from customers who are not buying from anyone, because nothing delivers the right benefit at an acceptable price.

Study different customer contexts and understand how they are different. It is impossible to understand the value of a benefit without first understanding where or when that benefit is desired, and how—if at all—customers benefit. Studying context will help identify constraints that rule out some solutions and the enablers that complement others.

Remember, simply because customers desire a benefit in one setting does not mean that they will desire it in another. Nor does it mean that the solution to a customer problem will work equally well in all contexts.

Consider all contexts as potentially different, potentially relevant sources of new information. Then use projective, experience-based interviewing, observational research, customer journey mapping and other deep-insight voice of
the customer methods to be sure you examine a problem from all perspectives.

As the story of Elkay’s revolutionary drinking fountain demonstrates, successful new products are rarely the outcome of pure inspiration. Instead, they occur because of a diligent, intentional strategy. Companies that make the voice of the customer the foundation of their innovation system—understanding who needs what, where and when, at the front end of new product development—launch better products that achieve success in the market.

When you reflect on your next step in becoming a better innovator, first consider whether you truly understand what a customer need means, what problems they are fixing. That way you will know what to look for the next time you study your customers, and you will be better positioned to create a solution that delivers value to them and to your company.

Identify the Right Customers

In B2B markets, the “customer” represents a collection of several stakeholders. A single person rarely buys and uses your product. Even when that’s the case, they are rarely the consumer and often have to satisfy downstream customers of their own.

Satisfying the customer really means satisfying many customers. This additional complexity can make it difficult to understand which customers’ needs are most relevant, and, consequently, where to deploy your limited resources for gathering the voice of the customer.

We recommend two best practices for homing in on the right customers to study. First, map your value chain. Beginning with your ultimate end user, trace a path back to the point at which your finished product leaves your company’s control, noting each link in the chain where the product changes hands until the end consumer has it. Each link can be considered a customer. Then ask yourself how likely it is that each customer can provide relevant information to influence product design. Use a broad perspective. For example, one of the biggest innovations in soft drinks, Coca-Cola’s Fridge Pack format, was conceived by aluminum giant Alcoa from insights identified in consumer shop-along research.

Second, within each link in the chain, map all the stakeholders to consider who may have relevant information for your product. We have found that stakeholders for any B2B product tend to play a generic set of roles, regardless of category.

Typically, there is:

• A specifier who designs the application
• An installer who sets up the product
• An operator who uses the product
• A maintainer who fixes the product when it breaks
• A purchaser who negotiates for and orders the product
• An economic buyer whose budget pays for the product

Sometimes the same person plays more than one role, and other times not all roles are present with each customer. However, unless you consider whether these roles exist and how they influence your market, you risk overlooking an important constituency whose opinion may make or break your product.

I have been fascinated with proper categorization and order as far back as memory allows. While categorization of physical items, devices and possessions is important, the categorization of ideas is critical to human progress.

We talk about music as baroque or romantic and art as impressionistic or abstract. We talk of tasks on a scale of time, the ever-present categorization mechanism. Categorization is key because it allows us to look at things in context. And classification is particularly important when we discuss our customers.

Companies devise user personas with interest- and preference-based categories to understand who their customers are. This simple but powerful mechanism has been used since the 1980s, allowing companies to build a mental picture of their target audience’s personality.

Product managers must connect the dots between a persona’s needs and the product features that best meet those unique needs. For instance, a fashion retail firm may refer to two user personas: Tanya and Skylar. Tanya is a bargain hunter. Price is most important to her, ahead of selection, status or convenience. Meanwhile, Skylar is a busy career woman who cares more about convenience than price.

If you head an ecommerce marketplace, Tanya’s opinions will carry more weight for features such as the clearance section, coupons and sales. Skylar is more likely to be a good representative for features like “buy online, pick up in store.”

To connect the dots effectively, you must have a strong understanding of your personas. And to do that, you must talk to your customers. Luckily, with the advent of social media, access to customers and associated analytics have increased in number, quality, influence and importance. However, it’s important to keep two key things in mind when you start listening to your customers.

We listen to real people, not abstract personas.

While personas are immeasurably helpful, it is critical to remember that personas appear on a scale or range, but real users are a more absolute value. As Chart 1 shows, not all customers represent the persona as closely or accurately.

If we assume we are correct in discovering and identifying our user persona, we see that Joan Baez and Knopfler closely embody our user base. Despite subtle differences in how they use and perceive the product, they are strongly aligned. To a degree, Emmylou is also aligned to the general trend, but her opinions must be strongly analyzed before they are incorporated. Her opinions may not represent the core market, but they have value when trying to understand the outliers. Finally, we have Cohen. While his opinions may have value for some product managers, listening to him could navigate your feature roadmap away from your unique selling proposition.

Everyone has a platform, but not everyone has influence.

Social media provides everyone with a pedestal and a voice, but not every voice has influence. The complexity of human networks and relationships often means that some voices are more shared, liked and retweeted than others. According to a recent article in Content Marketing, 64 percent of all articles received less than 20 shares across all networks, and 1 percent of the articles got 30 percent of all shares. The takeaway? Some voices are influencers, others are listeners. And there’s extra value in listening to key influencers.

Once we realize these two things, we realize that all customers should not be listened to equally. We can build a table to help us plot each voice and the relative importance and weight it should carry within the organization and our product plans.

Top Priority

Opinion Makers and Ideal Persona.These users are essential to our products. They are capable of generating new features and improving the quality of existing ones. Their input helps determine new features for our product roadmaps. Through their outsized influence on the community, they are also key to others forming an opinion about the perceived quality of our product.

High Priority

Active Fans and Ideal Persona OR Opinion Makers and Close to Ideal Persona. These two groups are critical to the product’s success and require close attention because of their complexity. The Opinion Makers who are not ideal personas may request features that veer us away from our unique selling proposition and the appeal to the core group. Active Fans offer their opinions less frequently but share more information with others; they influence prioritization of our product/feature roadmap. And although they may not generate ideas, they help us gauge which of the Opinion Makers’ ideas resonate.

Medium Priority

Active Fans and Close to Ideal Persona OR Opinion Makers and Somewhat Ideal Persona OR Bystanders Who Are Ideal Persona. These groups occupy a medium priority when it comes to listening to the voice of the customers. They are a good gauge of feature-set prioritization but occupy a supporting position to our earlier groups. The feature set, critiques and ideas generated by this group may or may not be applicable to the product, and their shares may not talk of the core appeal. Focus on looking for off-notes, criticisms and complaints from this group.

Low Priority

Active Fans and Somewhat Ideal Persona OR Bystanders Who Are Somewhat or Close to Ideal Persona. It is ironic that most of the actual buyers belong to the medium- and low-priority groups. After all, hierarchically, most people are Bystanders, not Influencers. These low-priority users have a low output when it comes to generating new content about our products; they are more likely to be the audience for such content. Even if some content is generated, it is unlikely to influence the masses.

Knowing your customers is critical; knowing which of your customers’ voices to value the most is key to keeping your product and roadmap prioritized and profitable.

]]>
Wed, 04 Nov 2015 14:10:13 -0400

I have been fascinated with proper categorization and order as far back as memory allows. While categorization of physical items, devices and possessions is important, the categorization of ideas is critical to human progress.

We talk about music as baroque or romantic and art as impressionistic or abstract. We talk of tasks on a scale of time, the ever-present categorization mechanism. Categorization is key because it allows us to look at things in context. And classification is particularly important when we discuss our customers.

Companies devise user personas with interest- and preference-based categories to understand who their customers are. This simple but powerful mechanism has been used since the 1980s, allowing companies to build a mental picture of their target audience’s personality.

Product managers must connect the dots between a persona’s needs and the product features that best meet those unique needs. For instance, a fashion retail firm may refer to two user personas: Tanya and Skylar. Tanya is a bargain hunter. Price is most important to her, ahead of selection, status or convenience. Meanwhile, Skylar is a busy career woman who cares more about convenience than price.

If you head an ecommerce marketplace, Tanya’s opinions will carry more weight for features such as the clearance section, coupons and sales. Skylar is more likely to be a good representative for features like “buy online, pick up in store.”

To connect the dots effectively, you must have a strong understanding of your personas. And to do that, you must talk to your customers. Luckily, with the advent of social media, access to customers and associated analytics have increased in number, quality, influence and importance. However, it’s important to keep two key things in mind when you start listening to your customers.

We listen to real people, not abstract personas.

While personas are immeasurably helpful, it is critical to remember that personas appear on a scale or range, but real users are a more absolute value. As Chart 1 shows, not all customers represent the persona as closely or accurately.

If we assume we are correct in discovering and identifying our user persona, we see that Joan Baez and Knopfler closely embody our user base. Despite subtle differences in how they use and perceive the product, they are strongly aligned. To a degree, Emmylou is also aligned to the general trend, but her opinions must be strongly analyzed before they are incorporated. Her opinions may not represent the core market, but they have value when trying to understand the outliers. Finally, we have Cohen. While his opinions may have value for some product managers, listening to him could navigate your feature roadmap away from your unique selling proposition.

Everyone has a platform, but not everyone has influence.

Social media provides everyone with a pedestal and a voice, but not every voice has influence. The complexity of human networks and relationships often means that some voices are more shared, liked and retweeted than others. According to a recent article in Content Marketing, 64 percent of all articles received less than 20 shares across all networks, and 1 percent of the articles got 30 percent of all shares. The takeaway? Some voices are influencers, others are listeners. And there’s extra value in listening to key influencers.

Once we realize these two things, we realize that all customers should not be listened to equally. We can build a table to help us plot each voice and the relative importance and weight it should carry within the organization and our product plans.

Top Priority

Opinion Makers and Ideal Persona.These users are essential to our products. They are capable of generating new features and improving the quality of existing ones. Their input helps determine new features for our product roadmaps. Through their outsized influence on the community, they are also key to others forming an opinion about the perceived quality of our product.

High Priority

Active Fans and Ideal Persona OR Opinion Makers and Close to Ideal Persona. These two groups are critical to the product’s success and require close attention because of their complexity. The Opinion Makers who are not ideal personas may request features that veer us away from our unique selling proposition and the appeal to the core group. Active Fans offer their opinions less frequently but share more information with others; they influence prioritization of our product/feature roadmap. And although they may not generate ideas, they help us gauge which of the Opinion Makers’ ideas resonate.

Medium Priority

Active Fans and Close to Ideal Persona OR Opinion Makers and Somewhat Ideal Persona OR Bystanders Who Are Ideal Persona. These groups occupy a medium priority when it comes to listening to the voice of the customers. They are a good gauge of feature-set prioritization but occupy a supporting position to our earlier groups. The feature set, critiques and ideas generated by this group may or may not be applicable to the product, and their shares may not talk of the core appeal. Focus on looking for off-notes, criticisms and complaints from this group.

Low Priority

Active Fans and Somewhat Ideal Persona OR Bystanders Who Are Somewhat or Close to Ideal Persona. It is ironic that most of the actual buyers belong to the medium- and low-priority groups. After all, hierarchically, most people are Bystanders, not Influencers. These low-priority users have a low output when it comes to generating new content about our products; they are more likely to be the audience for such content. Even if some content is generated, it is unlikely to influence the masses.

Knowing your customers is critical; knowing which of your customers’ voices to value the most is key to keeping your product and roadmap prioritized and profitable.

User experience (UX) design has become a strategic and competitive imperative for any modern product development effort. Fueled by iconic examples from companies such as Apple, product leaders are under increasing pressure to leverage user experience to meet and exceed consumer, competitive and market expectations.

Modern technology consumers drive the market. They have a clear sense of how technology must fit into their daily routines and existing digital ecosystems. In terms of user expectations, they no longer differentiate between work and home technologies, demanding the same utility, elegance and seamlessness from both. Yet despite prominent examples of successful user experiences, many product teams still struggle to define what UX designers do or how to effectively incorporate UX into
their efforts to deliver products.

Loosely defined, UX design is the discipline of creating the means by which users operate a product. The discipline attracts individuals with an innate and deep curiosity about how things work and are used. The best designers are internally driven to solve problems. They don’t sleep until they’ve solved a challenge and validated the solution with real users. UX designers live in details seemingly imperceptible to many, but that, when taken in aggregate, define the quality of the user experience. When empowered, designers have a key function on product teams, forging the central links between product management, engineers and users. Once engaged, the design process offers teams a means to identify and leverage opportunities to delight, innovate and drive competitive advantage. We saw this firsthand at LPL.

At LPL, our financial advisory technology creates operational efficiencies that allow our clients to focus on what they do best: serve their clients, the investors. It’s one of our key differentiators in the market. Our design team obsesses over how users interact with technology and how we can make those interactions better, faster and more efficient. In 2013, we had reached a crossroads. How could we provide the best user experience on a superior technology platform that would meet and exceed the expectations of our clients? How could we set ourselves apart as a leader with the technology solutions we provide so that our clients could manage and grow their businesses? And finally, how could we appeal to users across generations?

Because we emphasize client satisfaction, the user experience was a top priority as we set out to create our next-generation technology platform, ClientWorksSM. The LPL technology leadership team initiated the project in the summer of 2013, and it quickly grew into one of the most ambitious technology transformations LPL has ever undertaken.

Our goal was to dramatically improve the efficiency and utility of our platform. We understood that our success would be judged by our clients, the advisor community. And that meant that the function of UX design would be a prominent one throughout the project.

As a start, we conducted a thorough evaluation of the current platform from a variety of perspectives, including end user, back-office user, efficiency, productivity, device/browser support and more. We invested in extensive research within the advisor community, engaging directly with advisors, sales associates, and support and operations staff across all business segments.

In the end, the design team invested more than 1,500 hours in office visits, feedback sessions and shadowing, plus hundreds of hours with subject-matter experts within LPL. This investment dramatically increased our chances of identifying core challenges and compelling opportunities for these users.

Armed with this data, the design team identified essential task flows and built corresponding journey maps to represent the current and aspirational user experiences. These tools helped the product team better understand the context for product use and identify opportunities for efficiency and productivity, innovations and competitive differentiators.

We created high-level user narratives and supporting storyboards to help communicate the shared vision to internal stakeholders, a critical step in any product development. The team used the storyboards as a starting point and partnered with engineering to create an interactive, clickable prototype that facilitated more efficient end-user validation. The prototype brought the storyboard to life and helped the design team quickly work through lower-level design details with our engineering partners.

The interactive prototype evolved as we drove refinements and inputs from user and business feedback sessions into product development. The prototype was easy to change and refine, encouraging a great deal of agility within the product team in the early stages of the development cycle. Ultimately, we used the prototype’s front-end code as the basis for the product’s production-level user interface code, capitalizing on this early development investment.

After analyzing the inputs and design docs, we identified three imperatives upon which to build the new platform: flexibility, simplicity and integration, and customization. Through the above process we were able to deliver on them all:

Flexibility—We designed ClientWorks to be accessible from desktop and mobile devices, including tablets and smartphones. It allows our advisors to choose the platform and browser that best matches their business needs.

Simplicity and integration—The modern user interface intuitively supports essential task flows. For example, daily tasks such as client and account management, moving money, trading and new-account opening are designed to reflect conceptual models for those tasks that were already established in the minds of the users. Links are created across supporting sub-systems to ensure users can complete all tasks in context. We developed core interaction patterns and guidelines to support these task flows and then propagated them across the platform’s applications to increase approachability and raise system-wide usability measures. We continuously iterated task flows and screen designs until we exceeded the usability and simplicity targets.

Customization—ClientWorks encourags end users to tailor the platform to support the nuances of their specific business model. Sophisticated filtering controls allow advisors to collect the precise combination of information from across LPL systems to better understand their clients, accounts and business.

ClientWorks underwent an exhaustive set of measures on user satisfaction, task efficiency and productivity, achieving significant productivity improvements across the core tasks. Perhaps most compelling, we’ve provided advisors with near-instantaneous access to insights that previously took hours—or days—to achieve. ClientWorks also offers advisors a more
holistic view of their clients, associated accounts and their broader business, insights at the top of advisors’ wish lists.

Feedback has been overwhelmingly positive. Engaging our users directly in the design of ClientWorks allowed us to deliver compelling capabilities and build widespread support at LPL and within the advisor community. ClientWorks is now in active piloting with our early adopters.

Leading with the user experience has been critical to the success of ClientWorks. This approach ensured we had clearly defined business requirements driven from real-world use and balanced with internal business needs. We worked early on to establish UX designers as key contributors on the product teams and maintained a regular cadence of end-user interaction throughout the process. By leveraging the design team and the design process in this manner, we facilitated the creation of the compelling innovations necessary to drive market differentiation and product success.

]]>
Thu, 13 Aug 2015 00:00:00 -0400

User experience (UX) design has become a strategic and competitive imperative for any modern product development effort. Fueled by iconic examples from companies such as Apple, product leaders are under increasing pressure to leverage user experience to meet and exceed consumer, competitive and market expectations.

Modern technology consumers drive the market. They have a clear sense of how technology must fit into their daily routines and existing digital ecosystems. In terms of user expectations, they no longer differentiate between work and home technologies, demanding the same utility, elegance and seamlessness from both. Yet despite prominent examples of successful user experiences, many product teams still struggle to define what UX designers do or how to effectively incorporate UX into
their efforts to deliver products.

Loosely defined, UX design is the discipline of creating the means by which users operate a product. The discipline attracts individuals with an innate and deep curiosity about how things work and are used. The best designers are internally driven to solve problems. They don’t sleep until they’ve solved a challenge and validated the solution with real users. UX designers live in details seemingly imperceptible to many, but that, when taken in aggregate, define the quality of the user experience. When empowered, designers have a key function on product teams, forging the central links between product management, engineers and users. Once engaged, the design process offers teams a means to identify and leverage opportunities to delight, innovate and drive competitive advantage. We saw this firsthand at LPL.

At LPL, our financial advisory technology creates operational efficiencies that allow our clients to focus on what they do best: serve their clients, the investors. It’s one of our key differentiators in the market. Our design team obsesses over how users interact with technology and how we can make those interactions better, faster and more efficient. In 2013, we had reached a crossroads. How could we provide the best user experience on a superior technology platform that would meet and exceed the expectations of our clients? How could we set ourselves apart as a leader with the technology solutions we provide so that our clients could manage and grow their businesses? And finally, how could we appeal to users across generations?

Because we emphasize client satisfaction, the user experience was a top priority as we set out to create our next-generation technology platform, ClientWorksSM. The LPL technology leadership team initiated the project in the summer of 2013, and it quickly grew into one of the most ambitious technology transformations LPL has ever undertaken.

Our goal was to dramatically improve the efficiency and utility of our platform. We understood that our success would be judged by our clients, the advisor community. And that meant that the function of UX design would be a prominent one throughout the project.

As a start, we conducted a thorough evaluation of the current platform from a variety of perspectives, including end user, back-office user, efficiency, productivity, device/browser support and more. We invested in extensive research within the advisor community, engaging directly with advisors, sales associates, and support and operations staff across all business segments.

In the end, the design team invested more than 1,500 hours in office visits, feedback sessions and shadowing, plus hundreds of hours with subject-matter experts within LPL. This investment dramatically increased our chances of identifying core challenges and compelling opportunities for these users.

Armed with this data, the design team identified essential task flows and built corresponding journey maps to represent the current and aspirational user experiences. These tools helped the product team better understand the context for product use and identify opportunities for efficiency and productivity, innovations and competitive differentiators.

We created high-level user narratives and supporting storyboards to help communicate the shared vision to internal stakeholders, a critical step in any product development. The team used the storyboards as a starting point and partnered with engineering to create an interactive, clickable prototype that facilitated more efficient end-user validation. The prototype brought the storyboard to life and helped the design team quickly work through lower-level design details with our engineering partners.

The interactive prototype evolved as we drove refinements and inputs from user and business feedback sessions into product development. The prototype was easy to change and refine, encouraging a great deal of agility within the product team in the early stages of the development cycle. Ultimately, we used the prototype’s front-end code as the basis for the product’s production-level user interface code, capitalizing on this early development investment.

After analyzing the inputs and design docs, we identified three imperatives upon which to build the new platform: flexibility, simplicity and integration, and customization. Through the above process we were able to deliver on them all:

Flexibility—We designed ClientWorks to be accessible from desktop and mobile devices, including tablets and smartphones. It allows our advisors to choose the platform and browser that best matches their business needs.

Simplicity and integration—The modern user interface intuitively supports essential task flows. For example, daily tasks such as client and account management, moving money, trading and new-account opening are designed to reflect conceptual models for those tasks that were already established in the minds of the users. Links are created across supporting sub-systems to ensure users can complete all tasks in context. We developed core interaction patterns and guidelines to support these task flows and then propagated them across the platform’s applications to increase approachability and raise system-wide usability measures. We continuously iterated task flows and screen designs until we exceeded the usability and simplicity targets.

Customization—ClientWorks encourags end users to tailor the platform to support the nuances of their specific business model. Sophisticated filtering controls allow advisors to collect the precise combination of information from across LPL systems to better understand their clients, accounts and business.

ClientWorks underwent an exhaustive set of measures on user satisfaction, task efficiency and productivity, achieving significant productivity improvements across the core tasks. Perhaps most compelling, we’ve provided advisors with near-instantaneous access to insights that previously took hours—or days—to achieve. ClientWorks also offers advisors a more
holistic view of their clients, associated accounts and their broader business, insights at the top of advisors’ wish lists.

Feedback has been overwhelmingly positive. Engaging our users directly in the design of ClientWorks allowed us to deliver compelling capabilities and build widespread support at LPL and within the advisor community. ClientWorks is now in active piloting with our early adopters.

Leading with the user experience has been critical to the success of ClientWorks. This approach ensured we had clearly defined business requirements driven from real-world use and balanced with internal business needs. We worked early on to establish UX designers as key contributors on the product teams and maintained a regular cadence of end-user interaction throughout the process. By leveraging the design team and the design process in this manner, we facilitated the creation of the compelling innovations necessary to drive market differentiation and product success.

When I watch the TV show Bob the Builder with my kids, the product manager in me always takes issue with Bob’s catchphrase question, “Can we build it?” I guess it’s because I get asked this deceptively simple question all the time at work. I try not to reflexively shout, “Yes, we can!” as Bob’s construction-equipment friends always do. My more pragmatic response is usually, “Sure, we can build just about anything, but should we?” I guess, “Should we build it?” doesn’t make for such a great catchphrase, but it would make Bob a better product manager.

The most successful ideas usually originate from the customer in some form, but there’s no shortage of contributions from internal stakeholders. Predictably, these ideas from within the organization are often internally focused. For example, marketing wants new purchasing options within the product, or support requires new administrative tools. These are things that typically provide internal value, but not much for the end customer. So, how can you help limit internal requests that often have competing goals? The following three suggestions have worked well in my career.

Get Aligned on a Set of Objectives

If information security’s goal is security and uptime, and sales’ goal is revenue, it’s difficult to prioritize each of their needs in a common backlog. But if you, as the gatekeeper, can point to one set of top-down objectives, it becomes easier. If the organization’s objectives include increasing revenue per customer, and sales asks for a product widget that enables them to sell add-ons, it’s clear this request trumps others that don’t directly contribute to the revenue goal.
This list of objectives should be limited to a select few. It should be clearly publicized by top leadership. And representatives from each part of the organization should be involved in its creation so they feel a sense of ownership. Of course, if you work with other product teams, the first step is to make sure your own team is in alignment!

Create a Transparent Roadmap

When you tell someone outside of product management that their idea will be “added to the backlog,” how do you think they interpret that? I suspect they visualize the closing scene from Raiders of the Lost Ark, in which the ark is shelved in some giant warehouse, never to see the light of day. While some ideas deserve such a fate, you should be completely open about what is included—and excluded—in your roadmap.

I recommend publishing your roadmap internally for all to see. Make sure it includes a simple executive summary with relative priorities, and leave out requirement details. Each project or feature within your roadmap should reference the business objective it supports, and, whenever possible, supporting data such as survey results or user testing. Also, add a change log to show regular additions and adjustments. When everyone can see your purposeful, prioritized roadmap, the potential impact of inserting additional projects becomes clear.

Don’t forget that your roadmap can and should be used for self-promotion. Put a big checkmark on completed projects and include results data, such as a project’s effect on your net promoter score or conversion rates.

Know the Facts

Let’s face it. It’s easy to blame the product. You’ve probably been in a meeting where the following conversation occurred:

“You know, Big Scary Competitor just released Super Cool Feature.”

“Really? Why don’t we have Super Cool Feature?”

“We should! I bet that’s why sales are soft this month!”

Suddenly everyone is giving you that desperate “Can we build it?” look. This is when some relevant data can help avoid debate and objectively explain why Super Cool Feature should not be a priority.

Regularly spending time with both customers and data will supply you with the qualitative and quantitative ammunition needed to fend off impulse projects. As with your roadmap, your research should be shared openly in an effort to help everyone make more informed decisions. The best way is to take survey data, analytics, conversations, tests and observations, and craft them into stories that educate and excite your team. As Paul Simon said, “Facts can be turned into art if one is artful enough.”

As a product manager, you should enthusiastically welcome your colleagues into the ideation process. You never know from where the next great opportunity will come. But it’s your responsibility, for which you are uniquely qualified, to evaluate each idea against a focused set of objectives. Be consistent in your message, candid with information and perhaps a bit diplomatic. You’ll find requests from colleagues become more focused as they join you in asking, “Should we build it?”

]]>
Thu, 13 Aug 2015 00:00:00 -0400

When I watch the TV show Bob the Builder with my kids, the product manager in me always takes issue with Bob’s catchphrase question, “Can we build it?” I guess it’s because I get asked this deceptively simple question all the time at work. I try not to reflexively shout, “Yes, we can!” as Bob’s construction-equipment friends always do. My more pragmatic response is usually, “Sure, we can build just about anything, but should we?” I guess, “Should we build it?” doesn’t make for such a great catchphrase, but it would make Bob a better product manager.

The most successful ideas usually originate from the customer in some form, but there’s no shortage of contributions from internal stakeholders. Predictably, these ideas from within the organization are often internally focused. For example, marketing wants new purchasing options within the product, or support requires new administrative tools. These are things that typically provide internal value, but not much for the end customer. So, how can you help limit internal requests that often have competing goals? The following three suggestions have worked well in my career.

Get Aligned on a Set of Objectives

If information security’s goal is security and uptime, and sales’ goal is revenue, it’s difficult to prioritize each of their needs in a common backlog. But if you, as the gatekeeper, can point to one set of top-down objectives, it becomes easier. If the organization’s objectives include increasing revenue per customer, and sales asks for a product widget that enables them to sell add-ons, it’s clear this request trumps others that don’t directly contribute to the revenue goal.
This list of objectives should be limited to a select few. It should be clearly publicized by top leadership. And representatives from each part of the organization should be involved in its creation so they feel a sense of ownership. Of course, if you work with other product teams, the first step is to make sure your own team is in alignment!

Create a Transparent Roadmap

When you tell someone outside of product management that their idea will be “added to the backlog,” how do you think they interpret that? I suspect they visualize the closing scene from Raiders of the Lost Ark, in which the ark is shelved in some giant warehouse, never to see the light of day. While some ideas deserve such a fate, you should be completely open about what is included—and excluded—in your roadmap.

I recommend publishing your roadmap internally for all to see. Make sure it includes a simple executive summary with relative priorities, and leave out requirement details. Each project or feature within your roadmap should reference the business objective it supports, and, whenever possible, supporting data such as survey results or user testing. Also, add a change log to show regular additions and adjustments. When everyone can see your purposeful, prioritized roadmap, the potential impact of inserting additional projects becomes clear.

Don’t forget that your roadmap can and should be used for self-promotion. Put a big checkmark on completed projects and include results data, such as a project’s effect on your net promoter score or conversion rates.

Know the Facts

Let’s face it. It’s easy to blame the product. You’ve probably been in a meeting where the following conversation occurred:

“You know, Big Scary Competitor just released Super Cool Feature.”

“Really? Why don’t we have Super Cool Feature?”

“We should! I bet that’s why sales are soft this month!”

Suddenly everyone is giving you that desperate “Can we build it?” look. This is when some relevant data can help avoid debate and objectively explain why Super Cool Feature should not be a priority.

Regularly spending time with both customers and data will supply you with the qualitative and quantitative ammunition needed to fend off impulse projects. As with your roadmap, your research should be shared openly in an effort to help everyone make more informed decisions. The best way is to take survey data, analytics, conversations, tests and observations, and craft them into stories that educate and excite your team. As Paul Simon said, “Facts can be turned into art if one is artful enough.”

As a product manager, you should enthusiastically welcome your colleagues into the ideation process. You never know from where the next great opportunity will come. But it’s your responsibility, for which you are uniquely qualified, to evaluate each idea against a focused set of objectives. Be consistent in your message, candid with information and perhaps a bit diplomatic. You’ll find requests from colleagues become more focused as they join you in asking, “Should we build it?”

There are plenty of discussions in the agile community
about how agile teams work and develop over time. Often neglected or
poorly understood is how that work makes its way from the customer to
the team. Below is a blueprint for creating an effective and efficient
flow of work. I’ve included details but also left it flexible enough to
be customized for your company’s specific circumstances.

The Problem of Transparency

The blueprint for the product backlog flow focuses primarily on
increasing the visibility of how customer requests make their way to the
development team. Agile and lean startup emphasize the importance of
customer involvement from ideation to product release and beyond. By
making the customer request process more transparent, all
stakeholders—including customers, development, product management,
product marketing, marketing, sales and support—can provide input and
feedback. For the business, it places a real focus on customer requests
and personalizes customers for internal stakeholders. The customer
request ceases to be a number and becomes a problem that the customer
needs to solve. The entire business will then tackle the customer’s
problem as if they’re helping a friend.

The requestor, or more likely, the customer proxy or business
sponsor, also benefits from this transparency; now they can see how
their request is progressing. The customer proxy can keep the requestor
up to date on where their request sits.

Product Backlog Flow Overview

The product backlog flow consists of four sub-flows that occur
simultaneously, but independently. These flows deliver customer pains
and problems to the agile team. You can visualize them using a variation
of Mike Cohn’s Product Backlog Iceberg, shown at right.

These four flows work most efficiently with up-to-date accurate
prioritization and lean’s just-in-time techniques. Stories will move
from feature requests to future releases, then to release, and finally,
to sprint. Of course, features have a finite validity runway, the
timeframe where product/market fit remains intact and the product owner
and business believe that the feature’s core capability will not change.
Moving epics up the product backlog too soon introduces the risk of
wasted work if a feature is dropped for any reason.

From Ideation to Release: The Nilezon Example

Let’s start with a marketplace app called Nilezon, created at an
imaginary company by the same name. As a customer, not only do you want
the Nilezon app to remind you that your mom’s birthday is coming up in a
week, you’d like Nilezon to automatically send mom a birthday present
based on some criteria you previously entered. Mom gets her gift from
you, your forgetfulness is covered up and Nilezon gets paid from your
credit card. It’s a win-win-win situation.

You send your product enhancement idea to Nilezon and wait for the
new app release that includes your feature. Nilezon sends a thank-you
note and asks you to monitor Nilezon’s Twitter and Facebook pages for
product development news. Then Nilezon begins the process of
transforming your idea into a working product.

Feature Request State

Product management or marketing documents the new feature request
somewhere that’s accessible to all internal stakeholders. It could be in
a CRM tool, Confluence, a spreadsheet or even on a wall.

The idea goes through a review process based on some set of
established rules to see if it warrants further research. At Nilezon, it
is based on the number of similar requests and on the current and
likely feature sets of competitors. Lucky for you, this is not the first
request for such a feature. The next step then is for product
management and marketing to conduct a business feasibility study on this
latest feature request, now nicknamed Mom’s Gift. They must establish a
business model canvas to identify the problem, a possible solution,
unique value proposition and customer personas. Then they begin
validating the customer problem to verify that it’s worth solving.

At this point, it may make sense to add new feature requests to a
Kanban-like board to increase visibility and help product management and
marketing manage their portfolios (Figure 1). Throughout the process of
establishing a business case, ongoing visibility allows stakeholders to
make suggestions about the solution, how to market and how to sell the
new product feature, all of which are captured on the business model
canvas.

The timing for moving ideas into future release will vary by
company. For example, within Nilezon, there’s a small start-up component
that takes new ideas through to problem/solution fit and lays the
groundwork for establishing product/market fit. Once product management
and marketing are satisfied that there’s a valid business case—and the
feature has a high enough business priority—Mom’s Gift will be submitted
to the executive committee for approval.

Once the executive committee approves the feature, Mom’s Gift will
move onto the product backlog as a roadmap item. Without a definite
release date, it will go into the future release state.

Future Release State

Future release items in the product backlog represent a collection of
features encapsulating real customer problems that the business believes
are worth solving.

Items in the future release state have a more complete business
model canvas where problems are validated with customers, and cost and
revenue are roughly estimated. Each item is prioritized and includes a
description, customer acceptance criteria and an estimate.

At Nilezon, the Mom’s Gift feature has been formally added to the
product backlog. A lot of unknowns remain, including a high-level
architecture and validation for how the customer would set up criteria
for automatic gift selection. The product owner and a technical
subject-matter expert (SME) will do a rough feasibility study to
identify any high-level risks.

The strategic and tactical business concerns are the prime
focus while a feature epic rests in the future release state. The number
of product backlog items in future release will generally match the
company’s product roadmap length. If the roadmap projects the next 24
months, then you would have 24 months worth of estimated product backlog
items in future release and release.

During this stage, the product owner keeps an open and running
dialog with customers and potential customers. This is part of the
ongoing review to confirm or adjust the priority of the product backlog
based on business value. This priority can change at any time. Perhaps
the feature in the product backlog loses its competitive advantage or
there’s a spike in requests for it.

At Nilezon, the product team manages stakeholder expectations by
keeping them informed of any changes in business value or priority. The
product owner keeps the product backlog and business model canvases
available and accessible to all stakeholders.

Release State

A product backlog item moves to the release state when it’s the
highest-priority item in the future release column and a spot in the
release column opens up. The item is now tagged for a specific planned
release. The product team makes every effort to complete the business
model canvas for Mom’s Gift. All customer problems and solutions are
validated. The product owner and technical SME conduct a detailed
analysis including a high-level architecture and more comprehensive risk
analysis based on the design. User interface mockups are created and
validated with customers and users.

Features are reviewed and analyzed by the agile team that is
expected to implement the epic. The feature epic may be broken down to
facilitate estimation or to isolate its riskier aspects. The goal is to
confirm the feasibility of implementing the feature within a specific
release window.

The product owner is responsible for maintaining the priority of
product backlog items in the release state. Once a week, the product
owner of Mom’s Gift reevaluates the business value and priority of
product backlog items with the other product owners.

Sprint State

A product backlog item will move to the sprint state when it’s the
highest-priority item in the release column and a spot opens up in the
sprint column. The backlog item is broken down into smaller, more
manageable pieces of work that can be completed inside a single
iteration or sprint. Because development will have addressed outstanding
questions in earlier meetings, that team will already have a thorough
understanding of these small slices of functionality—known as
sprint-ready user stories.

It takes Nilezon’s development team four sprints to implement
Mom’s Gift. Each sprint adds functionality and capability, and the
results of each are shared with stakeholders and customers so they may
determine whether the development team and product owner are building
the right solution.

When the acceptance criteria are met for all user stories and
customers and stakeholders agree the feature is fit for its purpose, the
product backlog item moves into the “Done” state, completing the
journey through the product backlog.

Incorporating the four sub-flows into your product backlog flow will
increase the transparency of the customer request process and ensure
that each stakeholder can provide input and feedback. It places a real
focus on customer requests and personalizes those customers for internal
stakeholders.

]]>
Thu, 13 Aug 2015 00:00:00 -0400

There are plenty of discussions in the agile community
about how agile teams work and develop over time. Often neglected or
poorly understood is how that work makes its way from the customer to
the team. Below is a blueprint for creating an effective and efficient
flow of work. I’ve included details but also left it flexible enough to
be customized for your company’s specific circumstances.

The Problem of Transparency

The blueprint for the product backlog flow focuses primarily on
increasing the visibility of how customer requests make their way to the
development team. Agile and lean startup emphasize the importance of
customer involvement from ideation to product release and beyond. By
making the customer request process more transparent, all
stakeholders—including customers, development, product management,
product marketing, marketing, sales and support—can provide input and
feedback. For the business, it places a real focus on customer requests
and personalizes customers for internal stakeholders. The customer
request ceases to be a number and becomes a problem that the customer
needs to solve. The entire business will then tackle the customer’s
problem as if they’re helping a friend.

The requestor, or more likely, the customer proxy or business
sponsor, also benefits from this transparency; now they can see how
their request is progressing. The customer proxy can keep the requestor
up to date on where their request sits.

Product Backlog Flow Overview

The product backlog flow consists of four sub-flows that occur
simultaneously, but independently. These flows deliver customer pains
and problems to the agile team. You can visualize them using a variation
of Mike Cohn’s Product Backlog Iceberg, shown at right.

These four flows work most efficiently with up-to-date accurate
prioritization and lean’s just-in-time techniques. Stories will move
from feature requests to future releases, then to release, and finally,
to sprint. Of course, features have a finite validity runway, the
timeframe where product/market fit remains intact and the product owner
and business believe that the feature’s core capability will not change.
Moving epics up the product backlog too soon introduces the risk of
wasted work if a feature is dropped for any reason.

From Ideation to Release: The Nilezon Example

Let’s start with a marketplace app called Nilezon, created at an
imaginary company by the same name. As a customer, not only do you want
the Nilezon app to remind you that your mom’s birthday is coming up in a
week, you’d like Nilezon to automatically send mom a birthday present
based on some criteria you previously entered. Mom gets her gift from
you, your forgetfulness is covered up and Nilezon gets paid from your
credit card. It’s a win-win-win situation.

You send your product enhancement idea to Nilezon and wait for the
new app release that includes your feature. Nilezon sends a thank-you
note and asks you to monitor Nilezon’s Twitter and Facebook pages for
product development news. Then Nilezon begins the process of
transforming your idea into a working product.

Feature Request State

Product management or marketing documents the new feature request
somewhere that’s accessible to all internal stakeholders. It could be in
a CRM tool, Confluence, a spreadsheet or even on a wall.

The idea goes through a review process based on some set of
established rules to see if it warrants further research. At Nilezon, it
is based on the number of similar requests and on the current and
likely feature sets of competitors. Lucky for you, this is not the first
request for such a feature. The next step then is for product
management and marketing to conduct a business feasibility study on this
latest feature request, now nicknamed Mom’s Gift. They must establish a
business model canvas to identify the problem, a possible solution,
unique value proposition and customer personas. Then they begin
validating the customer problem to verify that it’s worth solving.

At this point, it may make sense to add new feature requests to a
Kanban-like board to increase visibility and help product management and
marketing manage their portfolios (Figure 1). Throughout the process of
establishing a business case, ongoing visibility allows stakeholders to
make suggestions about the solution, how to market and how to sell the
new product feature, all of which are captured on the business model
canvas.

The timing for moving ideas into future release will vary by
company. For example, within Nilezon, there’s a small start-up component
that takes new ideas through to problem/solution fit and lays the
groundwork for establishing product/market fit. Once product management
and marketing are satisfied that there’s a valid business case—and the
feature has a high enough business priority—Mom’s Gift will be submitted
to the executive committee for approval.

Once the executive committee approves the feature, Mom’s Gift will
move onto the product backlog as a roadmap item. Without a definite
release date, it will go into the future release state.

Future Release State

Future release items in the product backlog represent a collection of
features encapsulating real customer problems that the business believes
are worth solving.

Items in the future release state have a more complete business
model canvas where problems are validated with customers, and cost and
revenue are roughly estimated. Each item is prioritized and includes a
description, customer acceptance criteria and an estimate.

At Nilezon, the Mom’s Gift feature has been formally added to the
product backlog. A lot of unknowns remain, including a high-level
architecture and validation for how the customer would set up criteria
for automatic gift selection. The product owner and a technical
subject-matter expert (SME) will do a rough feasibility study to
identify any high-level risks.

The strategic and tactical business concerns are the prime
focus while a feature epic rests in the future release state. The number
of product backlog items in future release will generally match the
company’s product roadmap length. If the roadmap projects the next 24
months, then you would have 24 months worth of estimated product backlog
items in future release and release.

During this stage, the product owner keeps an open and running
dialog with customers and potential customers. This is part of the
ongoing review to confirm or adjust the priority of the product backlog
based on business value. This priority can change at any time. Perhaps
the feature in the product backlog loses its competitive advantage or
there’s a spike in requests for it.

At Nilezon, the product team manages stakeholder expectations by
keeping them informed of any changes in business value or priority. The
product owner keeps the product backlog and business model canvases
available and accessible to all stakeholders.

Release State

A product backlog item moves to the release state when it’s the
highest-priority item in the future release column and a spot in the
release column opens up. The item is now tagged for a specific planned
release. The product team makes every effort to complete the business
model canvas for Mom’s Gift. All customer problems and solutions are
validated. The product owner and technical SME conduct a detailed
analysis including a high-level architecture and more comprehensive risk
analysis based on the design. User interface mockups are created and
validated with customers and users.

Features are reviewed and analyzed by the agile team that is
expected to implement the epic. The feature epic may be broken down to
facilitate estimation or to isolate its riskier aspects. The goal is to
confirm the feasibility of implementing the feature within a specific
release window.

The product owner is responsible for maintaining the priority of
product backlog items in the release state. Once a week, the product
owner of Mom’s Gift reevaluates the business value and priority of
product backlog items with the other product owners.

Sprint State

A product backlog item will move to the sprint state when it’s the
highest-priority item in the release column and a spot opens up in the
sprint column. The backlog item is broken down into smaller, more
manageable pieces of work that can be completed inside a single
iteration or sprint. Because development will have addressed outstanding
questions in earlier meetings, that team will already have a thorough
understanding of these small slices of functionality—known as
sprint-ready user stories.

It takes Nilezon’s development team four sprints to implement
Mom’s Gift. Each sprint adds functionality and capability, and the
results of each are shared with stakeholders and customers so they may
determine whether the development team and product owner are building
the right solution.

When the acceptance criteria are met for all user stories and
customers and stakeholders agree the feature is fit for its purpose, the
product backlog item moves into the “Done” state, completing the
journey through the product backlog.

Incorporating the four sub-flows into your product backlog flow will
increase the transparency of the customer request process and ensure
that each stakeholder can provide input and feedback. It places a real
focus on customer requests and personalizes those customers for internal
stakeholders.

It can be difficult for your software company to stand out with a growing number of competitors in an industry that
seems to accelerate with each new technology wave. The good news is that a product’s user experience (UX) is one key differentiator that can help win the minds of customers. All other things being equal, a product with a great UX is easier to demo and sell than its competitors and results in higher customer satisfaction. In addition, an exceptional UX can help overcome real or perceived gaps in your solution.

Although the appearance of your product can affect the perception of value—and even of quality—usability is not only about visual appearance. It’s not just a matter of consistency, either. In fact, in some situations, you want to ensure that distinct functionality is presented in a way that reflects the differences. And while the user interface should reflect the brand in terms of tone and quality, it doesn’t have to match your website. Most importantly, UX isn’t a “skin” to add to a product after the fact; it is integral to the product.

Steve Jobs famously said, “Design is not just what it looks
like and feels like. Design is how it works.” Good interaction design is a component of UX work that is specifically dedicated
to the design of the product user interface.

How a product works is much more difficult to define or change once it’s been implemented, or even during implementation. And a strong UX team will help define not only the way features work, but also how to prioritize them and decide on the depth and scope of functionality.

So how does UX fit in with the rest of the product team? Think of UX as a complementary and often-overlapping area of focus. Much as a technical product manager or business analyst focuses on functional requirements, a UX professional is concerned with user requirements. There is common ground, but a good way to think about the delineation is that product management defines what the product does, focusing on the customer, and UX defines how the product does it, focusing on the end user. A business model of the application considers the customer and market and is the domain of product managers. A conceptual model considers how the product works related to the end user’s workflow and goals and is done by UX. Another way to look at it is that product management and UX work together on product utility, while UX specializes in usability.

UX can also be vital in communicating product vision to internal stakeholders. Like product management, they must have the ability to focus on short-term objectives, including upcoming user stories and sprints, and the product’s long-term vision and direction. The two roles can work together to add early visualizations of major features and milestones. This can help non-technical audiences understand the product direction without having to extrapolate from relatively abstract product backlogs. Both roles can aid and inspire the development group by providing a concrete goal to work toward, even while it is done incrementally.

UX is also vital to discovery. To improve the UX team’s effectiveness, it’s important to empower them to be the voice of the user, much as a product manager is the voice of the market. When you include your UX group in researching market problems and talking to end users, they develop an understanding of the target market. Customer site visits and usability testing—including testing of competitive products—are great ways to develop context. All UX teams should observe end users in their natural habitat to develop an understanding of how your customers work, then develop user personas based on their visits. Finally, involve your team in product management activities such as writing user stories and reviewing the product backlog. And at the development level, be sure to include them in daily standups.

It’s essential to have people on your team who can focus on UX—not just the UX design component, but the other critical activities such as user research, prototyping and usability testing. It isn’t something most other roles have the education, experience or expertise to do effectively, especially when they have other responsibilities, like day-to-day product management or writing code.

The ideal is to form a trio that includes a product manager, a UX professional and a lead developer to define and shape the product. Together, these three roles can drive requirements that consider the needs of end users, include input from your technical teams and ensure that your solution solves market problems. It will also save you time, money and frustration. And, you’ll have a better chance of delivering a high-quality product that gains your customers’ attention and outshines the competition.

Before you can build a product with a great UX, you
have to build and elevate the UX function within your organization. Start by hiring dedicated, experienced UX professionals if you can.

When hiring, keep in mind that UX, like product management, is a multidisciplinary field. Although there are an increasing number of dedicated certificate, undergraduate and graduate programs, you can also find people with UX experience who have backgrounds in other fields, including psychology, computer science and visual design. If you don’t already have usability or UX professionals on staff, consider asking local groups or communities for recommendations; you might even want to involve them in the interview process.

By empowering a UX team to be the voice of the user and incorporating UX into your product from the start, you’ll distinguish your product from the competition and help secure a loyal customer base.

]]>
Thu, 13 Aug 2015 00:00:00 -0400

It can be difficult for your software company to stand out with a growing number of competitors in an industry that
seems to accelerate with each new technology wave. The good news is that a product’s user experience (UX) is one key differentiator that can help win the minds of customers. All other things being equal, a product with a great UX is easier to demo and sell than its competitors and results in higher customer satisfaction. In addition, an exceptional UX can help overcome real or perceived gaps in your solution.

Although the appearance of your product can affect the perception of value—and even of quality—usability is not only about visual appearance. It’s not just a matter of consistency, either. In fact, in some situations, you want to ensure that distinct functionality is presented in a way that reflects the differences. And while the user interface should reflect the brand in terms of tone and quality, it doesn’t have to match your website. Most importantly, UX isn’t a “skin” to add to a product after the fact; it is integral to the product.

Steve Jobs famously said, “Design is not just what it looks
like and feels like. Design is how it works.” Good interaction design is a component of UX work that is specifically dedicated
to the design of the product user interface.

How a product works is much more difficult to define or change once it’s been implemented, or even during implementation. And a strong UX team will help define not only the way features work, but also how to prioritize them and decide on the depth and scope of functionality.

So how does UX fit in with the rest of the product team? Think of UX as a complementary and often-overlapping area of focus. Much as a technical product manager or business analyst focuses on functional requirements, a UX professional is concerned with user requirements. There is common ground, but a good way to think about the delineation is that product management defines what the product does, focusing on the customer, and UX defines how the product does it, focusing on the end user. A business model of the application considers the customer and market and is the domain of product managers. A conceptual model considers how the product works related to the end user’s workflow and goals and is done by UX. Another way to look at it is that product management and UX work together on product utility, while UX specializes in usability.

UX can also be vital in communicating product vision to internal stakeholders. Like product management, they must have the ability to focus on short-term objectives, including upcoming user stories and sprints, and the product’s long-term vision and direction. The two roles can work together to add early visualizations of major features and milestones. This can help non-technical audiences understand the product direction without having to extrapolate from relatively abstract product backlogs. Both roles can aid and inspire the development group by providing a concrete goal to work toward, even while it is done incrementally.

UX is also vital to discovery. To improve the UX team’s effectiveness, it’s important to empower them to be the voice of the user, much as a product manager is the voice of the market. When you include your UX group in researching market problems and talking to end users, they develop an understanding of the target market. Customer site visits and usability testing—including testing of competitive products—are great ways to develop context. All UX teams should observe end users in their natural habitat to develop an understanding of how your customers work, then develop user personas based on their visits. Finally, involve your team in product management activities such as writing user stories and reviewing the product backlog. And at the development level, be sure to include them in daily standups.

It’s essential to have people on your team who can focus on UX—not just the UX design component, but the other critical activities such as user research, prototyping and usability testing. It isn’t something most other roles have the education, experience or expertise to do effectively, especially when they have other responsibilities, like day-to-day product management or writing code.

The ideal is to form a trio that includes a product manager, a UX professional and a lead developer to define and shape the product. Together, these three roles can drive requirements that consider the needs of end users, include input from your technical teams and ensure that your solution solves market problems. It will also save you time, money and frustration. And, you’ll have a better chance of delivering a high-quality product that gains your customers’ attention and outshines the competition.

Before you can build a product with a great UX, you
have to build and elevate the UX function within your organization. Start by hiring dedicated, experienced UX professionals if you can.

When hiring, keep in mind that UX, like product management, is a multidisciplinary field. Although there are an increasing number of dedicated certificate, undergraduate and graduate programs, you can also find people with UX experience who have backgrounds in other fields, including psychology, computer science and visual design. If you don’t already have usability or UX professionals on staff, consider asking local groups or communities for recommendations; you might even want to involve them in the interview process.

By empowering a UX team to be the voice of the user and incorporating UX into your product from the start, you’ll distinguish your product from the competition and help secure a loyal customer base.

]]>
tag:feedblitz.com,2015-08-13:36474/http://feeds.feedblitz.com/~/158958202/0/pragmaticmarketing/articles/requirements/052c29d6f47d12ee765589a12393f52dhttp://pragmaticmarketing.com/agility_articles/redirect?id=7219http://feeds.feedblitz.com/~/158957460/0/pragmaticmarketing/articles/requirements~How-to-Build-a-Brilliant-Visual-Product-RoadmapBuilding roadmaps is a crucial part of a product manager’s job. Yet most product managers still use outdated tools for roadmapping—Excel, PowerPoint, wikis, etc. It’s painful. The good news is that there’s a better way.

Executives have a vision of the future. Sales and marketing teams want to be heard. And engineering is waiting for those detailed requirements and user stories. Great product managers must walk a fine line between managing inputs and distilling a plan.

The best product managers start with a “goal first” approach and work to build consensus before building and sharing their roadmap. To accomplish this and get to a plan of record, you need a collaborative roadmap that offers ongoing visibility.

Here are a few easy steps to help you create a brilliant visual roadmap.

1. Define your product strategy.

To start, you must clearly define your strategy by setting product vision, goals and initiatives for each product. Since major initiatives drive your goals, link them together. When this step is complete, you can see the relationships between your product lines, products, goals, initiatives and releases all on one screen. This helps you find orphan goals or initiatives that can’t be linked to high-level objectives.

2. Customize your roadmap based on who will view it.

Select which features to highlight and choose whether to present internal or external data. The external release date can be different than your internal release dates. It can also be rounded to a broader timeframe to be less precise (e.g. show releases by quarter).

For customer views, you can show the theme of the release and key features in which they will be interested. Internal stakeholders will want to understand the strategic importance, conveyed through goals and initiatives. You can also create views for specific customers, allowing your audience to see roadmaps that are relevant to their specific business objectives.

3. Bring releases and features together for a unified view.

Now it’s time to view your roadmap timeline. At this point, you have already chosen the releases you want to share and selected the features you want to highlight. You can build this defined view out in PowerPoint or Excel, or generate it with a simple click in a roadmapping tool where you can zoom in or out to get the exact view you want for your stakeholders. Each layer of the roadmap will represent a different set of data. Start with your products at the core, and work out to your releases at the edges.

4. Share your roadmap.

When you have the view you want, save it and/or share it with key stakeholders. Some software allows you to take nearly any view and publish it via a PDF or secure web page. Now you can proudly share your product plans and roadmap, easily keeping everyone up to date.

Everyone wants to see the same data—but each team wants to see it their own way. Product managers benefit from a focused approach that includes plenty of collaboration and planning to keep everyone on the same page. Now it’s time to build the perfect roadmap, share your plans with the team and build what matters.

]]>
Mon, 13 Apr 2015 00:00:00 -0400Building roadmaps is a crucial part of a product manager’s job. Yet most product managers still use outdated tools for roadmapping—Excel, PowerPoint, wikis, etc. It’s painful. The good news is that there’s a better way.

Executives have a vision of the future. Sales and marketing teams want to be heard. And engineering is waiting for those detailed requirements and user stories. Great product managers must walk a fine line between managing inputs and distilling a plan.

The best product managers start with a “goal first” approach and work to build consensus before building and sharing their roadmap. To accomplish this and get to a plan of record, you need a collaborative roadmap that offers ongoing visibility.

Here are a few easy steps to help you create a brilliant visual roadmap.

1. Define your product strategy.

To start, you must clearly define your strategy by setting product vision, goals and initiatives for each product. Since major initiatives drive your goals, link them together. When this step is complete, you can see the relationships between your product lines, products, goals, initiatives and releases all on one screen. This helps you find orphan goals or initiatives that can’t be linked to high-level objectives.

2. Customize your roadmap based on who will view it.

Select which features to highlight and choose whether to present internal or external data. The external release date can be different than your internal release dates. It can also be rounded to a broader timeframe to be less precise (e.g. show releases by quarter).

For customer views, you can show the theme of the release and key features in which they will be interested. Internal stakeholders will want to understand the strategic importance, conveyed through goals and initiatives. You can also create views for specific customers, allowing your audience to see roadmaps that are relevant to their specific business objectives.

3. Bring releases and features together for a unified view.

Now it’s time to view your roadmap timeline. At this point, you have already chosen the releases you want to share and selected the features you want to highlight. You can build this defined view out in PowerPoint or Excel, or generate it with a simple click in a roadmapping tool where you can zoom in or out to get the exact view you want for your stakeholders. Each layer of the roadmap will represent a different set of data. Start with your products at the core, and work out to your releases at the edges.

4. Share your roadmap.

When you have the view you want, save it and/or share it with key stakeholders. Some software allows you to take nearly any view and publish it via a PDF or secure web page. Now you can proudly share your product plans and roadmap, easily keeping everyone up to date.

Everyone wants to see the same data—but each team wants to see it their own way. Product managers benefit from a focused approach that includes plenty of collaboration and planning to keep everyone on the same page. Now it’s time to build the perfect roadmap, share your plans with the team and build what matters.

The old adage “you can’t improve what you can’t measure” indicates the need to know how you know. In traditional projects, milestones and key performance indicators (KPIs) measure project progress and individual contributions to that project.

But while agile scrum defines several milestones—sprint planning, daily standup, sprint review, sprint retrospective, backlog grooming—the milestones alone don’t provide any guarantees of progress or success. However, each one allows team members to inspect and adapt how—and what—they work on.

Below are nine key metrics I’ve identified specifically for measuring the success of scrum teams for keeping sprints on track. It’s followed by a checklist of items to look out for if your team is not measuring up.

The KPIs of Agile

Actual Stories Completed vs. Committed Stories – the team’s ability to understand and predict its capabilities. To measure, compare the number of stories committed to in sprint planning with the stories identified as completed in the sprint review.

Technical Debt Management – the known problems and issues delivered at the end of the sprint. It is usually measured by the number of bugs, but may also include deliverables such as training material, user documentation and delivery media.

Team Velocity – the consistency of the team’s estimates from sprint to sprint. Calculate by comparing story points completed in the current sprint with points completed in the previous sprint; aim for +/- 10 percent.

Quality Delivered to Customers – Are we building the product the customer needs? Does every sprint provide value to customers and become a potentially releasable piece of the product? It’s not necessarily a product ready to release but rather a work in progress, designed to solicit customer comments, opinions and suggestions. This can best be measured by surveying the customers and stakeholders.

Team Enthusiasm – a major component for a successful scrum team. If teammates aren’t enthusiastic, no process or methodology will help. Measuring enthusiasm can be done by observing various sprint meetings or, the most straightforward approach, simply asking team members “Do you feel happy?” and “How motivated do you feel?”

Retrospective Process Improvement – the scrum team’s ability to revise its development process to make it more effective and enjoyable for the next sprint. This can be measured using the count of retrospective items identified, the retrospective items the team committed to addressing and the items resolved by the end of the sprint.

Communication – how well the team, product owner, scrum master, customers and stakeholders are conducting open and honest communications. Through observing and listening you will get indications and clues about how well everyone is communicating.

Team’s Adherence to Scrum Rules and Engineering Practices – Although scrum doesn’t prescribe engineering practices—unlike XP—most companies define several of their own for their projects. You want to ensure that the scrum team follows the rules your company defines. This can be measured by counting the infractions that occur during each sprint.

Team’s Understanding of Sprint Scope and Goal – a subjective measure of how well the customer, product team and development team understand and focus on the sprint stories and goal. The goal is usually aligned with the intended customer value to be delivered and is defined in the acceptance criteria of the stories. This is best determined through day-to-day contact and interaction with the team and customer feedback.

The old adage “you can’t improve what you can’t measure” indicates the need to know how you know. In traditional projects, milestones and key performance indicators (KPIs) measure project progress and individual contributions to that project.

But while agile scrum defines several milestones—sprint planning, daily standup, sprint review, sprint retrospective, backlog grooming—the milestones alone don’t provide any guarantees of progress or success. However, each one allows team members to inspect and adapt how—and what—they work on.

Below are nine key metrics I’ve identified specifically for measuring the success of scrum teams for keeping sprints on track. It’s followed by a checklist of items to look out for if your team is not measuring up.

The KPIs of Agile

Actual Stories Completed vs. Committed Stories – the team’s ability to understand and predict its capabilities. To measure, compare the number of stories committed to in sprint planning with the stories identified as completed in the sprint review.

Technical Debt Management – the known problems and issues delivered at the end of the sprint. It is usually measured by the number of bugs, but may also include deliverables such as training material, user documentation and delivery media.

Team Velocity – the consistency of the team’s estimates from sprint to sprint. Calculate by comparing story points completed in the current sprint with points completed in the previous sprint; aim for +/- 10 percent.

Quality Delivered to Customers – Are we building the product the customer needs? Does every sprint provide value to customers and become a potentially releasable piece of the product? It’s not necessarily a product ready to release but rather a work in progress, designed to solicit customer comments, opinions and suggestions. This can best be measured by surveying the customers and stakeholders.

Team Enthusiasm – a major component for a successful scrum team. If teammates aren’t enthusiastic, no process or methodology will help. Measuring enthusiasm can be done by observing various sprint meetings or, the most straightforward approach, simply asking team members “Do you feel happy?” and “How motivated do you feel?”

Retrospective Process Improvement – the scrum team’s ability to revise its development process to make it more effective and enjoyable for the next sprint. This can be measured using the count of retrospective items identified, the retrospective items the team committed to addressing and the items resolved by the end of the sprint.

Communication – how well the team, product owner, scrum master, customers and stakeholders are conducting open and honest communications. Through observing and listening you will get indications and clues about how well everyone is communicating.

Team’s Adherence to Scrum Rules and Engineering Practices – Although scrum doesn’t prescribe engineering practices—unlike XP—most companies define several of their own for their projects. You want to ensure that the scrum team follows the rules your company defines. This can be measured by counting the infractions that occur during each sprint.

Team’s Understanding of Sprint Scope and Goal – a subjective measure of how well the customer, product team and development team understand and focus on the sprint stories and goal. The goal is usually aligned with the intended customer value to be delivered and is defined in the acceptance criteria of the stories. This is best determined through day-to-day contact and interaction with the team and customer feedback.

An effective product plan is designed to ensure that a new product delivers business value to a specific set of customers and meets certain financial goals. It describes the market opportunity, profiles target customers, specifies pricing, identifies financial goals and indicates key priorities for development and enhancement. Finally, it provides a roadmap for delivery for at least the next four quarters.

A comprehensive market requirements document might serve as the product plan for a new product. But the product plan should be updated annually for each product that continues to be offered to customers. Successive plans should focus on increasing that product’s effectiveness.

Product management creates a list of potential enhancements for the plan by soliciting customer feedback, speaking with sales teams, obtaining a list of the top technical support issues, surveying competitor features and getting new ideas from the market. After that, project prioritization typically occurs due to limited development resources.

Many companies apply an arbitrary prioritization scheme based on the perceived number of times a feature or product has been requested or how much revenue they think it can generate. The product team may also make assumptions about value based on how it thinks the product should be used. The team then creates a roadmap and release schedule using these priorities and voila, the product plan is done, right?

No, the product plan isn’t complete because the company’s strategy hasn’t yet been considered. So far, it’s merely a reaction to a somewhat random set of market facts and events. How exactly does the corporate strategy relate to the roadmap? The goal of almost any technology company is to increase revenues. Without a strategy to indicate how the company plans to increase revenue, almost any product plan could arguably help the company achieve its goal. But if the corporate strategy specifies how to generate new revenue, you can develop a product plan tailored to supporting that strategy.

For instance, your company could plan to grow revenue in a number of ways: by selling the flagship product in new geographic regions; establishing a new reseller channel; enhancing existing products to appeal to a wider base of customers; or developing new products that appeal to the existing customer base. Each decision carries significant implications for the product plan.

Selling in new geographic regions requires local language support and other specific regional requirements. Selling through a reseller channel requires multi-tier administration and branding. Enhancing products to appeal to a wider customer base involves profiling new customers to understand their unique needs and requirements. And finally, developing new products requires new analysis, requirements, design and development work.

Each strategy results in a different prioritization of projects and a different allocation of resources. The previously created product plan is reactionary and haphazard, while the product plan that responds to corporate strategy is directed and intentional.

The Strategic Planning Process

So let’s take a look at what an end-to-end product planning cycle might look like when integrated with the company’s strategic planning cycle. If a company resets its corporate strategy, financial plans and product plans once per year, the planning process ideally occurs during the fiscal year’s third and fourth quarters in preparation for the upcoming year.

There are five basic steps in the planning process:

Market review

Financial review

Corporate strategy

Product strategy

Product roadmap and release schedules

First, the product team presents a market review to executive management, sharing facts on market trends and opportunities, key customer needs, and competitor moves and positions. Although the product group keeps tabs on many of these items throughout the year, this is the opportunity to update information to ensure it’s complete and current. Other functions may be invited to provide their perspectives on the market and customers as well.

During the financial review, the finance organization presents results on the financial performance for the overall company, each sales channel and each product. Providing revenue and profitability by product is critical to making sound product decisions and developing effective strategies.

Next, the executive team outlines its corporate strategy, focusing on vision, financial goals and a plan to achieve those goals. The corporate strategy should be explicitly presented to the product management team to facilitate development of a product strategy.

The product team then develops its product strategy taking into account market dynamics, customer needs, financial goals and corporate strategy. It specifies the product changes that are needed and indicates the financial plan for each product area. Before proceeding to the next step, the executive team should review the product strategy to ensure alignment with the corporate strategy.

The final step involves developing a product roadmap and more detailed release plans for the coming quarters that are consistent with the product strategy. This roadmap becomes the official “product plan of record” and should be managed with formal change control procedures. This step is executed at the conclusion of the annual planning cycle and is repeated every three or four months—pending executive management approval—to respond to changing market conditions and deployment schedules.

The success of a product or services technology company is determined by the success of its products. Effective product plans address market and customer needs and support the company’s growth strategy. Creating effective product plans can only be accomplished if there is strong communication between the product and executive teams. The product team must clearly understand the company’s objectives in order to create product strategies and roadmaps that achieve them.

]]>
Thu, 20 Nov 2014 00:00:00 -0400

An effective product plan is designed to ensure that a new product delivers business value to a specific set of customers and meets certain financial goals. It describes the market opportunity, profiles target customers, specifies pricing, identifies financial goals and indicates key priorities for development and enhancement. Finally, it provides a roadmap for delivery for at least the next four quarters.

A comprehensive market requirements document might serve as the product plan for a new product. But the product plan should be updated annually for each product that continues to be offered to customers. Successive plans should focus on increasing that product’s effectiveness.

Product management creates a list of potential enhancements for the plan by soliciting customer feedback, speaking with sales teams, obtaining a list of the top technical support issues, surveying competitor features and getting new ideas from the market. After that, project prioritization typically occurs due to limited development resources.

Many companies apply an arbitrary prioritization scheme based on the perceived number of times a feature or product has been requested or how much revenue they think it can generate. The product team may also make assumptions about value based on how it thinks the product should be used. The team then creates a roadmap and release schedule using these priorities and voila, the product plan is done, right?

No, the product plan isn’t complete because the company’s strategy hasn’t yet been considered. So far, it’s merely a reaction to a somewhat random set of market facts and events. How exactly does the corporate strategy relate to the roadmap? The goal of almost any technology company is to increase revenues. Without a strategy to indicate how the company plans to increase revenue, almost any product plan could arguably help the company achieve its goal. But if the corporate strategy specifies how to generate new revenue, you can develop a product plan tailored to supporting that strategy.

For instance, your company could plan to grow revenue in a number of ways: by selling the flagship product in new geographic regions; establishing a new reseller channel; enhancing existing products to appeal to a wider base of customers; or developing new products that appeal to the existing customer base. Each decision carries significant implications for the product plan.

Selling in new geographic regions requires local language support and other specific regional requirements. Selling through a reseller channel requires multi-tier administration and branding. Enhancing products to appeal to a wider customer base involves profiling new customers to understand their unique needs and requirements. And finally, developing new products requires new analysis, requirements, design and development work.

Each strategy results in a different prioritization of projects and a different allocation of resources. The previously created product plan is reactionary and haphazard, while the product plan that responds to corporate strategy is directed and intentional.

The Strategic Planning Process

So let’s take a look at what an end-to-end product planning cycle might look like when integrated with the company’s strategic planning cycle. If a company resets its corporate strategy, financial plans and product plans once per year, the planning process ideally occurs during the fiscal year’s third and fourth quarters in preparation for the upcoming year.

There are five basic steps in the planning process:

Market review

Financial review

Corporate strategy

Product strategy

Product roadmap and release schedules

First, the product team presents a market review to executive management, sharing facts on market trends and opportunities, key customer needs, and competitor moves and positions. Although the product group keeps tabs on many of these items throughout the year, this is the opportunity to update information to ensure it’s complete and current. Other functions may be invited to provide their perspectives on the market and customers as well.

During the financial review, the finance organization presents results on the financial performance for the overall company, each sales channel and each product. Providing revenue and profitability by product is critical to making sound product decisions and developing effective strategies.

Next, the executive team outlines its corporate strategy, focusing on vision, financial goals and a plan to achieve those goals. The corporate strategy should be explicitly presented to the product management team to facilitate development of a product strategy.

The product team then develops its product strategy taking into account market dynamics, customer needs, financial goals and corporate strategy. It specifies the product changes that are needed and indicates the financial plan for each product area. Before proceeding to the next step, the executive team should review the product strategy to ensure alignment with the corporate strategy.

The final step involves developing a product roadmap and more detailed release plans for the coming quarters that are consistent with the product strategy. This roadmap becomes the official “product plan of record” and should be managed with formal change control procedures. This step is executed at the conclusion of the annual planning cycle and is repeated every three or four months—pending executive management approval—to respond to changing market conditions and deployment schedules.

The success of a product or services technology company is determined by the success of its products. Effective product plans address market and customer needs and support the company’s growth strategy. Creating effective product plans can only be accomplished if there is strong communication between the product and executive teams. The product team must clearly understand the company’s objectives in order to create product strategies and roadmaps that achieve them.

Your backlog is too long. You know it and your team knows it. Neglected items from two years ago are in there collecting dust. Long-forgotten issues that may or may not have
been fixed are festering in the chaotic dungeon of your backlog. Delete them.

“As a database, I would like to support Acme Standard ZXY 2.17-3.” Huh? What does ZXY 2.17-3 do? What does it mean? No value, no stakeholder. Delete it.

Product management often uses the backlog as a notepad, a place to jot down tasks before they slip from consciousness. Stop. Every item in your backlog has to be sorted, and you’re a human bubble sort (so inefficient your primary purpose is to show computer science students how not to sort lists). The fewer stories you have, the more meaningful they can be.

Task management systems like Getting Things Done encourage consolidating everything into one place to deal with later. Your backlog should not be one of these places. A large backlog slows your velocity, confuses your team and obfuscates your progress.

I once took over a three-year-old project and its backlog. As a new member on the team, I didn’t want to rock the boat. I read every issue, added structure that wasn’t there and tried to figure out themes from clues the old product manager had left behind. After two months, I’d cleaned things up. Each sprint had a strong goal, and the team was making progress. But things would get lost. Bugs that I knew were there were consumed by the black mass at the bottom of the list. I’d find three bugs created by different team members within a day of each other; apparently finding the original bug was harder than making a new one.

If you have these issues, it’s time to delete half your backlog. But how do you decide what’s important and what’s not?

If it doesn’t have a who, what and why, delete it. It’s not worth keeping stories without stakeholders, work or necessity. I cleared out 30 percent of my inherited backlog by following this mantra. Often technical debt will be tracked in the backlog without any justification for its importance. If you’re creating a technical debt story, be sure to justify the exact reason the work is necessary. Will it improve performance? Solve a bug? Make further development easier? If you’re not sure, delete it.

If the team can’t remember whether it was fixed, delete it. If it’s not worth recalling, it’s not worth existing. A former team member placed 30 items in the backlog, and we weren’t sure what they were, or whether they were important. We realized that if we didn’t know what the bug was, and couldn’t verify it, we could either forget about it, or it would pop up later where we could fully spec it out. We deleted 10 percent of our backlog this way.

If a feature request hasn’t been updated in months, delete it. It belongs on a roadmap or planning page, not your backlog. Another 10 percent of our backlog was “someday” items. Often these items were well-written specifications, but we weren’t going to complete them within the next year. I transferred them to our planning pages.

Don’t be afraid to consolidate stories. Stories should be smaller at the top, and bigger at the bottom. We often forget that part. For example, my team created specs for an epic—20 stories that were too big to complete in a single sprint—and then realized we had to leave it alone for three months. What did we do? We threw it away. Products morph with every sprint. If and when we returned to that epic, the tasks would have been out of date and useless; we’d have carried them as dead weight the entire time.

I heard from my old product team recently. That old backlog of mine? Deleted. Entirely. I didn’t shed a tear.

]]>
Thu, 20 Nov 2014 00:00:00 -0400

Your backlog is too long. You know it and your team knows it. Neglected items from two years ago are in there collecting dust. Long-forgotten issues that may or may not have
been fixed are festering in the chaotic dungeon of your backlog. Delete them.

“As a database, I would like to support Acme Standard ZXY 2.17-3.” Huh? What does ZXY 2.17-3 do? What does it mean? No value, no stakeholder. Delete it.

Product management often uses the backlog as a notepad, a place to jot down tasks before they slip from consciousness. Stop. Every item in your backlog has to be sorted, and you’re a human bubble sort (so inefficient your primary purpose is to show computer science students how not to sort lists). The fewer stories you have, the more meaningful they can be.

Task management systems like Getting Things Done encourage consolidating everything into one place to deal with later. Your backlog should not be one of these places. A large backlog slows your velocity, confuses your team and obfuscates your progress.

I once took over a three-year-old project and its backlog. As a new member on the team, I didn’t want to rock the boat. I read every issue, added structure that wasn’t there and tried to figure out themes from clues the old product manager had left behind. After two months, I’d cleaned things up. Each sprint had a strong goal, and the team was making progress. But things would get lost. Bugs that I knew were there were consumed by the black mass at the bottom of the list. I’d find three bugs created by different team members within a day of each other; apparently finding the original bug was harder than making a new one.

If you have these issues, it’s time to delete half your backlog. But how do you decide what’s important and what’s not?

If it doesn’t have a who, what and why, delete it. It’s not worth keeping stories without stakeholders, work or necessity. I cleared out 30 percent of my inherited backlog by following this mantra. Often technical debt will be tracked in the backlog without any justification for its importance. If you’re creating a technical debt story, be sure to justify the exact reason the work is necessary. Will it improve performance? Solve a bug? Make further development easier? If you’re not sure, delete it.

If the team can’t remember whether it was fixed, delete it. If it’s not worth recalling, it’s not worth existing. A former team member placed 30 items in the backlog, and we weren’t sure what they were, or whether they were important. We realized that if we didn’t know what the bug was, and couldn’t verify it, we could either forget about it, or it would pop up later where we could fully spec it out. We deleted 10 percent of our backlog this way.

If a feature request hasn’t been updated in months, delete it. It belongs on a roadmap or planning page, not your backlog. Another 10 percent of our backlog was “someday” items. Often these items were well-written specifications, but we weren’t going to complete them within the next year. I transferred them to our planning pages.

Don’t be afraid to consolidate stories. Stories should be smaller at the top, and bigger at the bottom. We often forget that part. For example, my team created specs for an epic—20 stories that were too big to complete in a single sprint—and then realized we had to leave it alone for three months. What did we do? We threw it away. Products morph with every sprint. If and when we returned to that epic, the tasks would have been out of date and useless; we’d have carried them as dead weight the entire time.

I heard from my old product team recently. That old backlog of mine? Deleted. Entirely. I didn’t shed a tear.

]]>
tag:feedblitz.com,2014-11-20:36474/http://feeds.feedblitz.com/~/158958214/0/pragmaticmarketing/articles/requirements/20030663aa62e2fed10bbe3f78a37c21http://pragmaticmarketing.com/agility_articles/redirect?id=6814http://feeds.feedblitz.com/~/158958218/0/pragmaticmarketing/articles/requirements~Product-Management-Versus-Development-One-Bag-and-a-CarryOnI hate the unnecessary inclusion of “versus” in titles and headings, because it often implies an adversarial relationship where one does not—or at least should not—exist. But while product management is often the greatest ally developers can have, there is some inherent tension between the two. Product management usually wants as many features in a product as possible, while developers and UX designers typically don’t want to be held accountable for fulfilling unrealistic expectations of what we can accomplish in a single product release. Figure 1 illustrates this conflict.

In my current role, I do a lot of negotiating back and forth between product management, their stakeholders and my product-development team trying to refine a set of requirements for a given product release or a roadmap of releases. This reminds me of a study I did back in my doctoral days, when I observed the differences between product management and development during a particular product’s development cycle. I summarized my observations using the metaphor of a couple packing to go on vacation.

Product management is the visionary, the one who imagines how great it will be when we get there and identifies all the things we’ll need to make it an enjoyable experience. They have an extensive list of things to pack—and frequently change or add things to the list up to the last minute. “Certainly, we’ll need flip flops for the beach, but we might go hiking on trails, so we should bring our tennis shoes too. Oh, and let’s bring some dress shoes for going out to dinner.”

The other, development, is thinking about getting there and is focusing on getting everything into one bag and a carry-on. Every time the former makes a change, the latter sighs deeply and unpacks everything, making room to add the new item. In some cases, this forces a swap with something already packed. Every accomplished packer knows the code: One does not simply throw a pair of flip-flops into a packed bag.

So to sum up, the product manager is the visionary, the one who imagines how great it will be when we get there and identifies all the things we’ll need to make it an enjoyable experience. The developer plays the role of the packer, the one who must fit all of that stuff into the constraints of reality.

Resolving the Tension

The obvious question is: How does one eliminate the tension between the two? I, for one, don’t think we should. I think the essence of design is to resolve tensions, not eliminate them. Some classic UX design tensions include convention versus innovation and control versus freedom. In these cases, the conflicting poles are not binary choices of this or that; rather, they are like the opposite ends of a speaker balance knob. More of this gives you less of that. The designer’s question is: What is the correct blend, given the problem I am trying to solve?

So, from the developer’s point of view, the first step is to recognize the validity of the product-management perspective and the value it brings. Remember that the trip to the airport and then to the vacation resort takes just a few hours. After that, you’ll be at the resort for an entire week. The benefits of packing lightly start to fade as you go horseback riding in flip flops. Similarly, the appeal of an efficient set of requirements that you can easily meet within the time and technology constraints can quickly wane, as a thin set of features struggles to succeed in a competitive marketplace. And in spite of your best intentions to expand upon the current release in the next one, the newest bright and shiny thing may have emerged. It is likely that the thin release will have to sustain your business presence in that marketplace, because there may be no reinforcements on the way.

The second step, from the developer’s point of view, is to recognize the validity of his or her perspective and recognize the value of constraint. There’s no need to be apologetic or shy about this. As the old project-management chestnut says: Better is the enemy of done. Your vacation ceases to be any fun at all if the airline doesn’t allow your luggage onto the plane. You can’t enjoy being there if you can’t find your way to get there.

Some Practical Techniques

Here are two simple techniques that help me to manage this productive tension between me and product management. One consists of making all of the hard requirements decisions before making any development investment; the other describes a useful yardstick with which to make such decisions.

Negotiation through artifacts. Every good packer knows the secret to packing is to stage everything before you begin. For example, if I am packing a suitcase, I lay out all of the clothes on the bed first. Similarly, if I am packing my car, I put all the luggage and stuff we need to take with us on the driveway first. Then I can make better decisions about what should go where and when I should put it there.

As a UX designer, I do the equivalent of staging when I create scenarios and wireframes, essentially laying out and agreeing on the user experience before we start investing significant development time and resources. The fight over what is in and what is out is a good fight; a fight that needs to happen. It’s just not a fight you want to have when the product is already in the middle of quality assurance. When you inevitably start throwing things away, you won’t want to have invested a lot of value into what you now must discard. I think one of the greatest values that user experience brings to the table is our ability to moderate these fights and negotiations by leveraging artifacts in which we’ve made little development investment.

Minimum viable product. Eric Reis, a Silicon Valley entrepreneur, popularized the concept of a minimum viable product, and agile developers have adopted this approach as a way of deflating large sets of requirements into manageable, independent chunks of development work. Essentially, an agile team asks: What is the least amount of functionality our product has to have before users would find themselves compelled to buy the product? This establishes the minimal target: the point below which you would have wasted all of your time and effort, because you would have nothing to show for it that anyone would buy. For example, Notepad or a similar text editor probably represents the minimum viable product for a word processor. If you couldn’t do at least that, you’d have nothing to take to market. Or stated in the converse, if you could do at least that, you’d have something someone would buy.

The nice thing about the concept of a minimum viable product is that everyone on a product team can pretty easily agree on the feature set that it represents. Establishing this baseline clears the landscape for the stickier rounds of negotiations, when you go through similar iterations of finding the next group of features that represent the next most important level of viability. For example, a next logical step for Notepad would be to introduce more sophisticated text formatting and allow rich text format (RTF) output. Adding features that got you just halfway there would provide no additional value. In short, you need to apply a sort of quantum theory to feature sets, such as “anything that doesn’t jump a gap that’s this big brings no value at all.”

When does this stop? When you run out of allocated development resources.

I once worked for an online bill payment company that wanted to design a financial planning application. To do this, we wanted to know how people went about paying their bills, so we did focus groups. Overwhelmingly, the most common technique was to save one’s bills until payday, then sit down and stack them in a priority order such as rent, car payment and so on. Participants then started paying bills from the top of the stack and continued writing checks until they ran out of either bills or money.

That’s pretty much how we decide what goes into a release, too. If we’ve run out of resources, but product management thinks there are essential features that are still on the table, they must reduce the requirements for other projects.

The end result of all this is that we have a reliable release roadmap in which product management and sales have confidence, because the packers keep the visionaries honest. And we have releases that offer true customer value, because the visionaries make sure the most valuable things get packed into a release. At the heart of this are the UX artifacts—like scenarios and wireframes—that facilitate productive discussions without a lot of development investment.

]]>
Mon, 18 Aug 2014 00:00:00 -0400I hate the unnecessary inclusion of “versus” in titles and headings, because it often implies an adversarial relationship where one does not—or at least should not—exist. But while product management is often the greatest ally developers can have, there is some inherent tension between the two. Product management usually wants as many features in a product as possible, while developers and UX designers typically don’t want to be held accountable for fulfilling unrealistic expectations of what we can accomplish in a single product release. Figure 1 illustrates this conflict.

In my current role, I do a lot of negotiating back and forth between product management, their stakeholders and my product-development team trying to refine a set of requirements for a given product release or a roadmap of releases. This reminds me of a study I did back in my doctoral days, when I observed the differences between product management and development during a particular product’s development cycle. I summarized my observations using the metaphor of a couple packing to go on vacation.

Product management is the visionary, the one who imagines how great it will be when we get there and identifies all the things we’ll need to make it an enjoyable experience. They have an extensive list of things to pack—and frequently change or add things to the list up to the last minute. “Certainly, we’ll need flip flops for the beach, but we might go hiking on trails, so we should bring our tennis shoes too. Oh, and let’s bring some dress shoes for going out to dinner.”

The other, development, is thinking about getting there and is focusing on getting everything into one bag and a carry-on. Every time the former makes a change, the latter sighs deeply and unpacks everything, making room to add the new item. In some cases, this forces a swap with something already packed. Every accomplished packer knows the code: One does not simply throw a pair of flip-flops into a packed bag.

So to sum up, the product manager is the visionary, the one who imagines how great it will be when we get there and identifies all the things we’ll need to make it an enjoyable experience. The developer plays the role of the packer, the one who must fit all of that stuff into the constraints of reality.

Resolving the Tension

The obvious question is: How does one eliminate the tension between the two? I, for one, don’t think we should. I think the essence of design is to resolve tensions, not eliminate them. Some classic UX design tensions include convention versus innovation and control versus freedom. In these cases, the conflicting poles are not binary choices of this or that; rather, they are like the opposite ends of a speaker balance knob. More of this gives you less of that. The designer’s question is: What is the correct blend, given the problem I am trying to solve?

So, from the developer’s point of view, the first step is to recognize the validity of the product-management perspective and the value it brings. Remember that the trip to the airport and then to the vacation resort takes just a few hours. After that, you’ll be at the resort for an entire week. The benefits of packing lightly start to fade as you go horseback riding in flip flops. Similarly, the appeal of an efficient set of requirements that you can easily meet within the time and technology constraints can quickly wane, as a thin set of features struggles to succeed in a competitive marketplace. And in spite of your best intentions to expand upon the current release in the next one, the newest bright and shiny thing may have emerged. It is likely that the thin release will have to sustain your business presence in that marketplace, because there may be no reinforcements on the way.

The second step, from the developer’s point of view, is to recognize the validity of his or her perspective and recognize the value of constraint. There’s no need to be apologetic or shy about this. As the old project-management chestnut says: Better is the enemy of done. Your vacation ceases to be any fun at all if the airline doesn’t allow your luggage onto the plane. You can’t enjoy being there if you can’t find your way to get there.

Some Practical Techniques

Here are two simple techniques that help me to manage this productive tension between me and product management. One consists of making all of the hard requirements decisions before making any development investment; the other describes a useful yardstick with which to make such decisions.

Negotiation through artifacts. Every good packer knows the secret to packing is to stage everything before you begin. For example, if I am packing a suitcase, I lay out all of the clothes on the bed first. Similarly, if I am packing my car, I put all the luggage and stuff we need to take with us on the driveway first. Then I can make better decisions about what should go where and when I should put it there.

As a UX designer, I do the equivalent of staging when I create scenarios and wireframes, essentially laying out and agreeing on the user experience before we start investing significant development time and resources. The fight over what is in and what is out is a good fight; a fight that needs to happen. It’s just not a fight you want to have when the product is already in the middle of quality assurance. When you inevitably start throwing things away, you won’t want to have invested a lot of value into what you now must discard. I think one of the greatest values that user experience brings to the table is our ability to moderate these fights and negotiations by leveraging artifacts in which we’ve made little development investment.

Minimum viable product. Eric Reis, a Silicon Valley entrepreneur, popularized the concept of a minimum viable product, and agile developers have adopted this approach as a way of deflating large sets of requirements into manageable, independent chunks of development work. Essentially, an agile team asks: What is the least amount of functionality our product has to have before users would find themselves compelled to buy the product? This establishes the minimal target: the point below which you would have wasted all of your time and effort, because you would have nothing to show for it that anyone would buy. For example, Notepad or a similar text editor probably represents the minimum viable product for a word processor. If you couldn’t do at least that, you’d have nothing to take to market. Or stated in the converse, if you could do at least that, you’d have something someone would buy.

The nice thing about the concept of a minimum viable product is that everyone on a product team can pretty easily agree on the feature set that it represents. Establishing this baseline clears the landscape for the stickier rounds of negotiations, when you go through similar iterations of finding the next group of features that represent the next most important level of viability. For example, a next logical step for Notepad would be to introduce more sophisticated text formatting and allow rich text format (RTF) output. Adding features that got you just halfway there would provide no additional value. In short, you need to apply a sort of quantum theory to feature sets, such as “anything that doesn’t jump a gap that’s this big brings no value at all.”

When does this stop? When you run out of allocated development resources.

I once worked for an online bill payment company that wanted to design a financial planning application. To do this, we wanted to know how people went about paying their bills, so we did focus groups. Overwhelmingly, the most common technique was to save one’s bills until payday, then sit down and stack them in a priority order such as rent, car payment and so on. Participants then started paying bills from the top of the stack and continued writing checks until they ran out of either bills or money.

That’s pretty much how we decide what goes into a release, too. If we’ve run out of resources, but product management thinks there are essential features that are still on the table, they must reduce the requirements for other projects.

The end result of all this is that we have a reliable release roadmap in which product management and sales have confidence, because the packers keep the visionaries honest. And we have releases that offer true customer value, because the visionaries make sure the most valuable things get packed into a release. At the heart of this are the UX artifacts—like scenarios and wireframes—that facilitate productive discussions without a lot of development investment.

]]>
tag:feedblitz.com,2014-08-18:36474/http://feeds.feedblitz.com/~/158958218/0/pragmaticmarketing/articles/requirements/d20ecefebd08cabc8cb49ddefff762eehttp://pragmaticmarketing.com/agility_articles/redirect?id=6815http://feeds.feedblitz.com/~/158958224/0/pragmaticmarketing/articles/requirements~How-a-Tech-Background-Empowers-Product-ProfessionalsI’ve been asked repeatedly over the last decade if having a technical background is required to be successful as a product manager. The answer is no. But it has certainly helped me to be more effective. This is a personal and situational question which has no crisp answer—but sharing some of my experiences may help you to work more effectively with, or as, a product manager with a technical background.

Internal Wiring

I don’t know if I went to school for engineering because of how my brain was wired, or if Carnegie Mellon rewired my brain for me—but I always say it is where I “learned how to learn.” How I approach learning, and how I apply different analytical techniques to synthesis, situational analysis and development of insights is driven by how my brain is wired. In product-management speak, the way I learn things is a distinctive competence, and it makes me objectively better as a product manager. I would argue that this is because of my technical background. I would expect people with similar backgrounds to have similar advantages.

The Inside Track

I tend to work most frequently with businesses that incorporate software development into developing solutions for their customers. I happen to have also spent several years developing software—and eventually leading teams which were developing software. This arcane knowledge of the secret handshake has helped me develop effective working relationships with the team members who are actually creating the product. When you do something, you learn it more viscerally than if you only read about it. Building on this deeper level of insight, which only comes from doing, is one way to develop camaraderie with the team of people creating your product.

The Temporary Crutch

In terms of what you already know, a technical background only helps for a short while. Eventually, the information you acquired will become irrelevant—and eventually it will mislead. Imagine trying to apply pre-SQL database perspectives to conversations about NoSQL and distributed data storage architectures and the ensuing release-planning activities. You can also, of course, have a bundle of technical knowledge, which is not relevant to your problem domain. Bernoulli’s equation is not going to help me increase conversion rates on a website, or help me assess the value of continuous integration.

My approach to applying the things I already know—or used to know—is to leverage that knowledge for shared context in conversation, pattern recognition when being exposed to new-to-me information and generally applying the principles of learning to whatever is in front of me. I do not try to apply the knowledge to solutioning, beyond using it to guide some directed questioning or to help with hypothesis formulation.

One of the phrases I remember from Pragmatic Marketing’s training was a question from my instructor: “If you are going to do their job, who is going to do your job?” That very question helps me walk away when I start to get too far down into the weeds in discussing how we’re going to solve the problems. It is a slippery slope, especially when you really enjoy technology and secretly wish you could be coding away (or designing or testing) with the rest of the team.

Helpful, with a Twist

The crux of it is that the benefit of having a technical background does not come from participating in the technical work, but from how it helps you collaborate with the technical team. Collaboration is a soft skill, and it is the one that is broadly helped by having technical wiring.

Sometimes, we work on products that are helping our customers to solve problems in a technical domain. In these cases, being technical can help quite a bit—and may even be genuinely required—in developing an understanding of your market.

Consider, for example, developing the staffing schedule for a large hospital. You need to be able to synthesize technical problems, combining the abstract mathematical problem (the nurse-rostering problem is a classic computational conundrum) with the business appreciation for defining the “good enough” solution. In my opinion, developing insights about how to compete in this market requires you to be able to appreciate the mathematical complexity of the value proposition, so that you neither assume it is trivial nor intractable. This is a problem that people will pay to solve. It is also a problem that requires a combination of technical solution and business perspective.

At the end of the day, if you’re developing a product that is addressing a particularly technical problem, I don’t believe you can be effective without sufficient “technical wiring” in your brain to be able to fully appreciate the challenges (and opportunities) in play. One of the better (and very technical) product managers I have worked with happens to have a degree in history, but his brain was absolutely wired to be able to think technically. Demonstrated success in a technical role (or education) is a likely indicator, but an imperfect filter.

In a Nutshell

Having an existing body of technical knowledge in your head is of limited and suspect utility. Limited because it is more useful in application than in collaboration, and suspect because it will become irrelevant or even wrong faster than you will expect. I think of this as a circumstantial outcome of having a technical background—not an asset that can be directly leveraged.

But even when you’re creating products that are not “technical,” having a technical perspective can help you significantly in the process of creating those products. And that’s not because it helps you do any of the technical heavy lifting, but because it helps you work more effectively with the people who are doing the technical work.

]]>
Mon, 18 Aug 2014 00:00:00 -0400I’ve been asked repeatedly over the last decade if having a technical background is required to be successful as a product manager. The answer is no. But it has certainly helped me to be more effective. This is a personal and situational question which has no crisp answer—but sharing some of my experiences may help you to work more effectively with, or as, a product manager with a technical background.

Internal Wiring

I don’t know if I went to school for engineering because of how my brain was wired, or if Carnegie Mellon rewired my brain for me—but I always say it is where I “learned how to learn.” How I approach learning, and how I apply different analytical techniques to synthesis, situational analysis and development of insights is driven by how my brain is wired. In product-management speak, the way I learn things is a distinctive competence, and it makes me objectively better as a product manager. I would argue that this is because of my technical background. I would expect people with similar backgrounds to have similar advantages.

The Inside Track

I tend to work most frequently with businesses that incorporate software development into developing solutions for their customers. I happen to have also spent several years developing software—and eventually leading teams which were developing software. This arcane knowledge of the secret handshake has helped me develop effective working relationships with the team members who are actually creating the product. When you do something, you learn it more viscerally than if you only read about it. Building on this deeper level of insight, which only comes from doing, is one way to develop camaraderie with the team of people creating your product.

The Temporary Crutch

In terms of what you already know, a technical background only helps for a short while. Eventually, the information you acquired will become irrelevant—and eventually it will mislead. Imagine trying to apply pre-SQL database perspectives to conversations about NoSQL and distributed data storage architectures and the ensuing release-planning activities. You can also, of course, have a bundle of technical knowledge, which is not relevant to your problem domain. Bernoulli’s equation is not going to help me increase conversion rates on a website, or help me assess the value of continuous integration.

My approach to applying the things I already know—or used to know—is to leverage that knowledge for shared context in conversation, pattern recognition when being exposed to new-to-me information and generally applying the principles of learning to whatever is in front of me. I do not try to apply the knowledge to solutioning, beyond using it to guide some directed questioning or to help with hypothesis formulation.

One of the phrases I remember from Pragmatic Marketing’s training was a question from my instructor: “If you are going to do their job, who is going to do your job?” That very question helps me walk away when I start to get too far down into the weeds in discussing how we’re going to solve the problems. It is a slippery slope, especially when you really enjoy technology and secretly wish you could be coding away (or designing or testing) with the rest of the team.

Helpful, with a Twist

The crux of it is that the benefit of having a technical background does not come from participating in the technical work, but from how it helps you collaborate with the technical team. Collaboration is a soft skill, and it is the one that is broadly helped by having technical wiring.

Sometimes, we work on products that are helping our customers to solve problems in a technical domain. In these cases, being technical can help quite a bit—and may even be genuinely required—in developing an understanding of your market.

Consider, for example, developing the staffing schedule for a large hospital. You need to be able to synthesize technical problems, combining the abstract mathematical problem (the nurse-rostering problem is a classic computational conundrum) with the business appreciation for defining the “good enough” solution. In my opinion, developing insights about how to compete in this market requires you to be able to appreciate the mathematical complexity of the value proposition, so that you neither assume it is trivial nor intractable. This is a problem that people will pay to solve. It is also a problem that requires a combination of technical solution and business perspective.

At the end of the day, if you’re developing a product that is addressing a particularly technical problem, I don’t believe you can be effective without sufficient “technical wiring” in your brain to be able to fully appreciate the challenges (and opportunities) in play. One of the better (and very technical) product managers I have worked with happens to have a degree in history, but his brain was absolutely wired to be able to think technically. Demonstrated success in a technical role (or education) is a likely indicator, but an imperfect filter.

In a Nutshell

Having an existing body of technical knowledge in your head is of limited and suspect utility. Limited because it is more useful in application than in collaboration, and suspect because it will become irrelevant or even wrong faster than you will expect. I think of this as a circumstantial outcome of having a technical background—not an asset that can be directly leveraged.

But even when you’re creating products that are not “technical,” having a technical perspective can help you significantly in the process of creating those products. And that’s not because it helps you do any of the technical heavy lifting, but because it helps you work more effectively with the people who are doing the technical work.

]]>
tag:feedblitz.com,2014-08-18:36474/http://feeds.feedblitz.com/~/158958224/0/pragmaticmarketing/articles/requirements/820a8cc08e2379aa0bdf5e5207f835c3http://pragmaticmarketing.com/agility_articles/redirect?id=6821http://feeds.feedblitz.com/~/158958230/0/pragmaticmarketing/articles/requirements~Confessions-of-a-Nontechnical-Product-ManagerMy friend Matt was helping a client adopt a more Agile software product development process. His first question to me was: “How do we test a product manager applicant’s computer science chops?” To which I replied, “Who says your PM has to code?”

As a “nontechnical” product manager and entrepreneur who has overseen the development of many projects from mobile games to multiplatform marketing campaigns, I get variations on this question a lot. Some employers and clients fear that product professionals who don’t code won’t be able to communicate properly with their development team.

Of course, every project is different but the two roles require very different skill sets. Personally, my lack of formal computer science training has never held me back, and can often be an asset. Here’s six tips for current and aspiring product professionals who don’t code:

1. The Product Is the Boss

A good product professional is a leader, but is not a boss. The product is the boss. Now here comes the corny business-book truism: Your top priority at work is to make your boss look good. Your job in a product role is not to bark orders at designers and developers, nor is it to be subservient to them. Rather, you are there to communicate effectively with the entire team including executives, marketers and salespeople, to make sure the product is great. A truly great product professional keeps the team focused on that common goal and helps determine the best path to get there.

2. Tell a Great Story

In user-focused design and development, we can think of each feature as a “story.” When we describe each development task, we are essentially writing a story that will lay out the scenarios and requirements that allow the developer to dive in and formulate a solution. It’s important to remember that although we must define success, we don’t need to know the exact path to get there. In fact, good story writing is not technical at all. It is a unique language that bridges user needs with desired outcome; developing this skill requires empathy, attention to detail and systematic thinking. Tell your team a great story and they will come back with the technical requirements and functions that bring it to life.

3. Be Available

Writing a good story is an important first step, but your job doesn’t end there. You are an integral member of the team, and you must be available to facilitate, translate and communicate. Need a better feature description? Rewrite it and make sure everybody is on board. Having a communication problem with a team member? Fix it ASAP. Don’t hide behind Gannt charts or shift the blame when challenges arise. Tackle things head on with your team, and listen to them.

4. Ask Questions

I’ve never worked with a developer who wasn’t able to easily diagram a stack for me or describe how an important subsystem works. Most of the time, developers are excited to share their knowledge. You just have to ask. This understanding is an advantage that product professionals with a computer science background bring to the table, but it’s a skill that a nontechnical PM can easily develop. The more of this knowledge you accumulate, the better you’ll be at predicting how long things will take—and this will help you and your management team prioritize. In the meantime, you have options. Bring a developer into planning meetings to contribute, or avoid committing to timelines without consulting the team.

If you walk away from a technical conversation a bit confused, jot down the bits you understood and the things you didn’t and research it on your own later. It’s probably not imperative that you understand a complex development system now, but a better understanding may help inform a conversation or decision in the future.

5. Speak Up!

You may not know the ins and outs of C++ or how to whip up a web app in a couple of hours using Ruby on Rails, but don’t underestimate the value of your own experience and common sense. Even the best developers need help sometimes. And a good product professional can be a trusted collaborator to bounce ideas off of.

When a developer asks me to help with a technical problem, I start by discussing the feature from the user’s perspective. Then I transition to the developer’s point of view. Is the basic logic sound or are there holes in it? Is there a more simple way to get the same results? Is it built on, pulling from or sending out to other parts of the application? You’d be surprised how valuable your new perspective can be. Sometimes just identifying the trade-offs with technical decisions can help your developer choose a direction to best move forward. Code isn’t the only language developers know. Every feature is a series of rules that follow a system of logic that can be discussed in plain old English—or in diagrams, visuals and even emoticons if your coder doesn’t speak English (which I’ve also experienced).

6. Listen

Just as you may be able to inspire a coding solution for your developer, every team member can inspire product solutions. Encourage the entire team to volunteer feature ideas, share cool new capabilities, voice insights from data that may have been missed and find easy wins.

Being a good listener and making sure everybody is comfortable sharing their ideas will ultimately be a huge benefit to the product. And you definitely don’t need technical training for this skill—which may be the most important one.

]]>
Mon, 18 Aug 2014 00:00:00 -0400My friend Matt was helping a client adopt a more Agile software product development process. His first question to me was: “How do we test a product manager applicant’s computer science chops?” To which I replied, “Who says your PM has to code?”

As a “nontechnical” product manager and entrepreneur who has overseen the development of many projects from mobile games to multiplatform marketing campaigns, I get variations on this question a lot. Some employers and clients fear that product professionals who don’t code won’t be able to communicate properly with their development team.

Of course, every project is different but the two roles require very different skill sets. Personally, my lack of formal computer science training has never held me back, and can often be an asset. Here’s six tips for current and aspiring product professionals who don’t code:

1. The Product Is the Boss

A good product professional is a leader, but is not a boss. The product is the boss. Now here comes the corny business-book truism: Your top priority at work is to make your boss look good. Your job in a product role is not to bark orders at designers and developers, nor is it to be subservient to them. Rather, you are there to communicate effectively with the entire team including executives, marketers and salespeople, to make sure the product is great. A truly great product professional keeps the team focused on that common goal and helps determine the best path to get there.

2. Tell a Great Story

In user-focused design and development, we can think of each feature as a “story.” When we describe each development task, we are essentially writing a story that will lay out the scenarios and requirements that allow the developer to dive in and formulate a solution. It’s important to remember that although we must define success, we don’t need to know the exact path to get there. In fact, good story writing is not technical at all. It is a unique language that bridges user needs with desired outcome; developing this skill requires empathy, attention to detail and systematic thinking. Tell your team a great story and they will come back with the technical requirements and functions that bring it to life.

3. Be Available

Writing a good story is an important first step, but your job doesn’t end there. You are an integral member of the team, and you must be available to facilitate, translate and communicate. Need a better feature description? Rewrite it and make sure everybody is on board. Having a communication problem with a team member? Fix it ASAP. Don’t hide behind Gannt charts or shift the blame when challenges arise. Tackle things head on with your team, and listen to them.

4. Ask Questions

I’ve never worked with a developer who wasn’t able to easily diagram a stack for me or describe how an important subsystem works. Most of the time, developers are excited to share their knowledge. You just have to ask. This understanding is an advantage that product professionals with a computer science background bring to the table, but it’s a skill that a nontechnical PM can easily develop. The more of this knowledge you accumulate, the better you’ll be at predicting how long things will take—and this will help you and your management team prioritize. In the meantime, you have options. Bring a developer into planning meetings to contribute, or avoid committing to timelines without consulting the team.

If you walk away from a technical conversation a bit confused, jot down the bits you understood and the things you didn’t and research it on your own later. It’s probably not imperative that you understand a complex development system now, but a better understanding may help inform a conversation or decision in the future.

5. Speak Up!

You may not know the ins and outs of C++ or how to whip up a web app in a couple of hours using Ruby on Rails, but don’t underestimate the value of your own experience and common sense. Even the best developers need help sometimes. And a good product professional can be a trusted collaborator to bounce ideas off of.

When a developer asks me to help with a technical problem, I start by discussing the feature from the user’s perspective. Then I transition to the developer’s point of view. Is the basic logic sound or are there holes in it? Is there a more simple way to get the same results? Is it built on, pulling from or sending out to other parts of the application? You’d be surprised how valuable your new perspective can be. Sometimes just identifying the trade-offs with technical decisions can help your developer choose a direction to best move forward. Code isn’t the only language developers know. Every feature is a series of rules that follow a system of logic that can be discussed in plain old English—or in diagrams, visuals and even emoticons if your coder doesn’t speak English (which I’ve also experienced).

6. Listen

Just as you may be able to inspire a coding solution for your developer, every team member can inspire product solutions. Encourage the entire team to volunteer feature ideas, share cool new capabilities, voice insights from data that may have been missed and find easy wins.

Being a good listener and making sure everybody is comfortable sharing their ideas will ultimately be a huge benefit to the product. And you definitely don’t need technical training for this skill—which may be the most important one.

Role definition. A clearer structure helps everyone share in the product development process more effectively

Collaboration points. Discover where the two can best work together: user and market research, user stories, usability testing and other methods that produce results that can immediately be put into action

Practical recommendations. How to handle continually changing UX in an agile environment

Conflict resolution. How to best handle when UX and product disagree

Join Stephanie Bergman of ADP and Patrick Neeman of Usability Counts for this lively discussion on the product management/UX designer relationship from both sides of the fence.

Role definition. A clearer structure helps everyone share in the product development process more effectively

Collaboration points. Discover where the two can best work together: user and market research, user stories, usability testing and other methods that produce results that can immediately be put into action

Practical recommendations. How to handle continually changing UX in an agile environment

Conflict resolution. How to best handle when UX and product disagree

Join Stephanie Bergman of ADP and Patrick Neeman of Usability Counts for this lively discussion on the product management/UX designer relationship from both sides of the fence.

Kanban,” which is Japanese for “signboard” or “billboard,” is a method in just-in-time (JIT) production systems where cards are used to signal when materials should be moved to a different location. I first heard about kanban boards being used for Agile software development about a year ago and determined that it was an inexpensive experiment to try in an effort to improve the focus and visibility of our software development process.

Why Use a Kanban Board?

You are likely already familiar with burn down charts, which show how many tasks remain and how much time is left in a sprint or iteration. Like a burn down chart, a kanban board is a visual representation of the work left to do.

However, a burn down chart typically corresponds to an iteration or sprint, while a kanban board can correspond to any milestone. It shows specific tasks to be done before a project is complete, and a project can be anything with true business value—whether it’s a feature set, getting a product to alpha or some other business goal.

Also, because burn down charts require keeping track of the ideal and actual tasks for an iteration and should be updated daily, they can be somewhat tedious to create and maintain. A kanban board does not show the time remaining or how much time each task is expected to take, and this simplicity and flexibility is one of the reasons kanban boards are easy to implement.

Implementing Kanban Boards

We use kanban boards to keep on track and monitor the progress of high-profile projects. First, we write down each task that absolutely has to get done on its own sticky note. While it may be tempting to include “desirable” tasks as well, this will slow down the project. One of the benefits of using a kanban board is that it forces the stakeholders to reach agreement on what is absolutely required. Since our development process is done using an agile process, it’s not unusual for the required tasks to change as the project is underway—and you can add or remove tasks as needed.

The sticky notes are then placed on a whiteboard (or extra-large sticky note) in the developer bullpen or other highly visible location. The title of the project should be written on top, and it should be divided up into workflow categories, such as “to do,” “in progress,” “quality assurance,” “alpha,” “done” or whatever descriptions make sense for your environment.

Initially, all the sticky notes go in the “to do” section. Then as items get worked on, they move to the “in progress” section, continuing on to “done” as they work their way through the development process. If an item doesn’t pass testing, it goes back to “in progress.” A quick glance at the kanban board tells the product manager and other stakeholders where tasks are in the development cycle, whether or not the project is progressing and how close a project is to being done.

Kanban boards can be implemented at any time during a project. We typically create the kanban board after the project is in progress, rather than at the very beginning. This way the project is better understood, so there will be less churning of sticky notes. Once all the sticky notes are on the board, the stakeholders can decide if the board works as is, if any tasks should be deferred or if the project needs to be redefined. Being able to see a visual representation of the work to do on a project makes it easier for us to decide if anything is missing or if there’s too much work for the desired completion date.

HIGH TECH OR LOW TECH?

As you might expect with a tool used by developers, people have written software to implement kanban boards. An advantage to using software is that if it links to your development software, the boards are updated automatically in real time. For teams that are geographically distributed, kanban board software might be a good choice. Our programmers are all in the same location and usually in the same room, so we currently use a low-tech implementation. A couple of things to keep in mind when making the decision between a high-tech and low-tech implementation are that 1) the product manager must be able to access and maintain it and 2) the kanban boards should be highly visible.

This article focused on using kanban boards for software development, but because of their flexibility, there’s no reason they can’t be used for other projects such as releases or marketing activities. You can even implement them while continuing to use burn down charts, using burn down charts to track iterations or sprints and kanban boards to provide greater visibility to major business initiatives that might span multiple iterations.

]]>
Thu, 24 Oct 2013 00:00:00 -0400

Kanban,” which is Japanese for “signboard” or “billboard,” is a method in just-in-time (JIT) production systems where cards are used to signal when materials should be moved to a different location. I first heard about kanban boards being used for Agile software development about a year ago and determined that it was an inexpensive experiment to try in an effort to improve the focus and visibility of our software development process.

Why Use a Kanban Board?

You are likely already familiar with burn down charts, which show how many tasks remain and how much time is left in a sprint or iteration. Like a burn down chart, a kanban board is a visual representation of the work left to do.

However, a burn down chart typically corresponds to an iteration or sprint, while a kanban board can correspond to any milestone. It shows specific tasks to be done before a project is complete, and a project can be anything with true business value—whether it’s a feature set, getting a product to alpha or some other business goal.

Also, because burn down charts require keeping track of the ideal and actual tasks for an iteration and should be updated daily, they can be somewhat tedious to create and maintain. A kanban board does not show the time remaining or how much time each task is expected to take, and this simplicity and flexibility is one of the reasons kanban boards are easy to implement.

Implementing Kanban Boards

We use kanban boards to keep on track and monitor the progress of high-profile projects. First, we write down each task that absolutely has to get done on its own sticky note. While it may be tempting to include “desirable” tasks as well, this will slow down the project. One of the benefits of using a kanban board is that it forces the stakeholders to reach agreement on what is absolutely required. Since our development process is done using an agile process, it’s not unusual for the required tasks to change as the project is underway—and you can add or remove tasks as needed.

The sticky notes are then placed on a whiteboard (or extra-large sticky note) in the developer bullpen or other highly visible location. The title of the project should be written on top, and it should be divided up into workflow categories, such as “to do,” “in progress,” “quality assurance,” “alpha,” “done” or whatever descriptions make sense for your environment.

Initially, all the sticky notes go in the “to do” section. Then as items get worked on, they move to the “in progress” section, continuing on to “done” as they work their way through the development process. If an item doesn’t pass testing, it goes back to “in progress.” A quick glance at the kanban board tells the product manager and other stakeholders where tasks are in the development cycle, whether or not the project is progressing and how close a project is to being done.

Kanban boards can be implemented at any time during a project. We typically create the kanban board after the project is in progress, rather than at the very beginning. This way the project is better understood, so there will be less churning of sticky notes. Once all the sticky notes are on the board, the stakeholders can decide if the board works as is, if any tasks should be deferred or if the project needs to be redefined. Being able to see a visual representation of the work to do on a project makes it easier for us to decide if anything is missing or if there’s too much work for the desired completion date.

HIGH TECH OR LOW TECH?

As you might expect with a tool used by developers, people have written software to implement kanban boards. An advantage to using software is that if it links to your development software, the boards are updated automatically in real time. For teams that are geographically distributed, kanban board software might be a good choice. Our programmers are all in the same location and usually in the same room, so we currently use a low-tech implementation. A couple of things to keep in mind when making the decision between a high-tech and low-tech implementation are that 1) the product manager must be able to access and maintain it and 2) the kanban boards should be highly visible.

This article focused on using kanban boards for software development, but because of their flexibility, there’s no reason they can’t be used for other projects such as releases or marketing activities. You can even implement them while continuing to use burn down charts, using burn down charts to track iterations or sprints and kanban boards to provide greater visibility to major business initiatives that might span multiple iterations.

User stories are one of the most misunderstood and misapplied artifacts when implementing Agile development. At first glance, they look like requirements—and it can be very easy for a team to sit in a room and crank out a bunch of them when under the gun to generate work for the next sprint.

The user story format is: As a <type of user>, I want to <something> because <benefit>. Let's look at an example: "As a first-time book buyer, I want to find the perfect mystery novel by reading staff reviews so I won’t waste my money buying bad books."

What is wrong with this user story? Maybe nothing; maybe everything. Are customers asking for staff recommendations? Or did the product team decide staff recommendations were cool and then write the user story from that premise? Even if customers are asking for staff recommendations, does that mean that we should build it?

The ultimate goal of the customer in this story seems to be to find the perfect mystery novel, without wasting time and money on bad books. But which is more important to the customer, saving time or saving money? And would providing staff reviews actually help customers achieve that goal?

You need to start with a story about a user and what their actual problem is. From there you can refine the story into the user's goal—and ultimately the requirements you're looking for.

Story about a user. When driving along unfamiliar roads, I often catch a glimpse of an interesting-looking shop or restaurant. Unfortunately, I am usually on my way to an appointment, it is unsafe to pull over or the place is closed. It would be great if I had some way to remember the name of the place or its location so I could research it and return if I want.

User story. As a driver who frequently travels in unfamiliar areas, I want the ability for my GPS to record my current location so that I can remember interesting places. It's not a terrible description, but is this an illustrative example or a requirement?

Request. I wish I could remember my car’s current location when I am driving along an unfamiliar route. That way if I see someplace interesting, I can easily locate it later. That's a better description and is implementation-free.

User goal. I would like to be able to return to interesting-looking shops, restaurants or locations that I encounter while driving in unfamiliar areas. That is the best, distilled to the ultimate user goal.

The Who, What and What

Goals are your first description of stakeholder intentions and your first insight into their requirements. Goals must be analyzed and refined into realistic and measurable targets if you are to have any hope of building the right thing.

Whatever format you use to convey the "requirements" to the project team is a matter of preference. What truly matters is that you convey a clear understanding of (1) who will be using the product, (2) what the goals of each stakeholder group are and (3) what context the product will be operated in.

Let’s dig a little deeper into each of these three areas.

Who will be using your product? It seems pretty straightforward, right? But keep in mind that all users are stakeholders, but not all stakeholders are users. (In the broadest sense, a stakeholder can be anyone who has influence on your project or product.) When we think of stakeholders, the following two come to mind immediately: the person who will actually be using the product and the person who is funding your project. But wait! What about the person who is actually purchasing the end product? Sometimes they are the same as the end user, often they are not.

The classic example is dog food: While the dog is certainly the user of the product, you can’t forget that the owner is the one making the purchase decision—and the stakeholder that you have to influence initially. In software purchases, it is often the same: The people who will be making the purchasing decision may ultimately never directly use your product, so you must understand what affects their decisions as they evaluate and compare products.

Best practice. Don’t rely solely on information from the project sponsors and other managers to understand “the requirements.” Meet with the people who will be “in the trenches” using the product. Get them to tell you stories. To better understand goals, ask questions like “how does the company measure your performance?” and “what would you need to accomplish to have a great day, week, month?”

What are the goals of each stakeholder group? Think about the last time you entered in a timesheet for work. Did you get excited about the endless array of options to capture each hour of work that you performed? Did you agonize over how to record each hour of work, so that you can be sure that your organizational budget will be as accurate as possible? If you answered yes to either of these questions, you are probably a project manager.

Unfortunately, when someone went about designing the timesheet software, they probably didn’t take into account the goals of the other stakeholder groups like the software developers, business analysts and testers. Their goal was most likely to be able to input time as quickly and easily as possible and get back to doing what gets evaluated—a classic case of conflicting stakeholder goals.

Best practice. Create a stakeholder/goal matrix and surface conflicting goals among internal stakeholders. This is most easily accomplished in a facilitated workshop where disagreements will surely emerge that can be learned from.

What context will the product be operated in? Specifically, once we know what we are designing, what conditions of the physical environment do we need to take into account? For my scenario of wanting to be able to remember interesting places, we probably would need to understand the laws for operating a device while driving, the amount of noise in the car (for speech recognition to work), the speed we anticipate the car to be moving at when the driver notices someplace of interest, etc. And we should factor these into the product.

Best practice. Rather than analyzing the operating context at only a static point in time, try to envision how your product will be used throughout its life cycle. Develop prototypes and have team members or potential users role-play scenarios. Get out of your office and observe people in their work environment, while they are doing the tasks that fulfill their goals. Be observant. Ask about sticky notes and files of papers that seem out of place.

Take It Further

After validating that there is a large enough group of users with the same goal—and the willingness to pay for a solution—you can start riding around with a sample population, developing personas and using other techniques to uncover user needs and behaviors. That information can help you evolve additional requirements.

Current reality. I am driving on my way to visit my friend Ed and I see an interesting-looking antique shop that I would like to check out.

Here are my current workarounds:

If possible, pull over and write down the name and address of the store.

Attempt to write down the name of the store while driving.

Attempt to remember the name of the store and when reaching a safe point during the route, try to locate via Points of Interest functionality on GPS.

If I successfully remembered all or part of the name, search the Internet later to obtain the address, then input the address into the GPS.

If time allows, delay driving to my destination and drive to the store, realizing that the store might not be open.

These are the requirements:

Since the user will be driving while initiating this functionality, it is imperative not to break the driver’s concentration—since this could lead to an accident.

Since the user will most likely spot the desired location as he is either quickly approaching it or has just passed it, the functionality must be able to determine and record the car’s current location within 3-5 seconds.

Other requirements that surface

Future scenario.This is a future-based story used to envision one possible way that we could fulfill the targeted user’s goals. I am driving on my way to visit my friend Ed, and I see an interesting-looking antique shop that I would like to check out. Unfortunately, I don’t have the time to stop, because I told Ed that I would be there at precisely 2 p.m. sharp. It would be great if I could just hit a button as I pass the antique shop and the GPS would record the closest street address or nearest intersection. I would like to be able to retrieve that information later and save it in My Favorites.

That brings me to the most important best practice of all: Empty your cup. There is a famous story about a university professor who kept talking about Zen to a Zen master, while the master poured tea until it overflowed. "You are like the cup," the master said to the professor. "You are full to overflowing with opinions and ideas and grand theories. If you are to find what you seek, you must first empty yourself."

And like that professor, you must rid yourself of preconceived ideas and prejudices if you want to truly understand user goals.

User stories are one of the most misunderstood and misapplied artifacts when implementing Agile development. At first glance, they look like requirements—and it can be very easy for a team to sit in a room and crank out a bunch of them when under the gun to generate work for the next sprint.

The user story format is: As a <type of user>, I want to <something> because <benefit>. Let's look at an example: "As a first-time book buyer, I want to find the perfect mystery novel by reading staff reviews so I won’t waste my money buying bad books."

What is wrong with this user story? Maybe nothing; maybe everything. Are customers asking for staff recommendations? Or did the product team decide staff recommendations were cool and then write the user story from that premise? Even if customers are asking for staff recommendations, does that mean that we should build it?

The ultimate goal of the customer in this story seems to be to find the perfect mystery novel, without wasting time and money on bad books. But which is more important to the customer, saving time or saving money? And would providing staff reviews actually help customers achieve that goal?

You need to start with a story about a user and what their actual problem is. From there you can refine the story into the user's goal—and ultimately the requirements you're looking for.

Story about a user. When driving along unfamiliar roads, I often catch a glimpse of an interesting-looking shop or restaurant. Unfortunately, I am usually on my way to an appointment, it is unsafe to pull over or the place is closed. It would be great if I had some way to remember the name of the place or its location so I could research it and return if I want.

User story. As a driver who frequently travels in unfamiliar areas, I want the ability for my GPS to record my current location so that I can remember interesting places. It's not a terrible description, but is this an illustrative example or a requirement?

Request. I wish I could remember my car’s current location when I am driving along an unfamiliar route. That way if I see someplace interesting, I can easily locate it later. That's a better description and is implementation-free.

User goal. I would like to be able to return to interesting-looking shops, restaurants or locations that I encounter while driving in unfamiliar areas. That is the best, distilled to the ultimate user goal.

The Who, What and What

Goals are your first description of stakeholder intentions and your first insight into their requirements. Goals must be analyzed and refined into realistic and measurable targets if you are to have any hope of building the right thing.

Whatever format you use to convey the "requirements" to the project team is a matter of preference. What truly matters is that you convey a clear understanding of (1) who will be using the product, (2) what the goals of each stakeholder group are and (3) what context the product will be operated in.

Let’s dig a little deeper into each of these three areas.

Who will be using your product? It seems pretty straightforward, right? But keep in mind that all users are stakeholders, but not all stakeholders are users. (In the broadest sense, a stakeholder can be anyone who has influence on your project or product.) When we think of stakeholders, the following two come to mind immediately: the person who will actually be using the product and the person who is funding your project. But wait! What about the person who is actually purchasing the end product? Sometimes they are the same as the end user, often they are not.

The classic example is dog food: While the dog is certainly the user of the product, you can’t forget that the owner is the one making the purchase decision—and the stakeholder that you have to influence initially. In software purchases, it is often the same: The people who will be making the purchasing decision may ultimately never directly use your product, so you must understand what affects their decisions as they evaluate and compare products.

Best practice. Don’t rely solely on information from the project sponsors and other managers to understand “the requirements.” Meet with the people who will be “in the trenches” using the product. Get them to tell you stories. To better understand goals, ask questions like “how does the company measure your performance?” and “what would you need to accomplish to have a great day, week, month?”

What are the goals of each stakeholder group? Think about the last time you entered in a timesheet for work. Did you get excited about the endless array of options to capture each hour of work that you performed? Did you agonize over how to record each hour of work, so that you can be sure that your organizational budget will be as accurate as possible? If you answered yes to either of these questions, you are probably a project manager.

Unfortunately, when someone went about designing the timesheet software, they probably didn’t take into account the goals of the other stakeholder groups like the software developers, business analysts and testers. Their goal was most likely to be able to input time as quickly and easily as possible and get back to doing what gets evaluated—a classic case of conflicting stakeholder goals.

Best practice. Create a stakeholder/goal matrix and surface conflicting goals among internal stakeholders. This is most easily accomplished in a facilitated workshop where disagreements will surely emerge that can be learned from.

What context will the product be operated in? Specifically, once we know what we are designing, what conditions of the physical environment do we need to take into account? For my scenario of wanting to be able to remember interesting places, we probably would need to understand the laws for operating a device while driving, the amount of noise in the car (for speech recognition to work), the speed we anticipate the car to be moving at when the driver notices someplace of interest, etc. And we should factor these into the product.

Best practice. Rather than analyzing the operating context at only a static point in time, try to envision how your product will be used throughout its life cycle. Develop prototypes and have team members or potential users role-play scenarios. Get out of your office and observe people in their work environment, while they are doing the tasks that fulfill their goals. Be observant. Ask about sticky notes and files of papers that seem out of place.

Take It Further

After validating that there is a large enough group of users with the same goal—and the willingness to pay for a solution—you can start riding around with a sample population, developing personas and using other techniques to uncover user needs and behaviors. That information can help you evolve additional requirements.

Current reality. I am driving on my way to visit my friend Ed and I see an interesting-looking antique shop that I would like to check out.

Here are my current workarounds:

If possible, pull over and write down the name and address of the store.

Attempt to write down the name of the store while driving.

Attempt to remember the name of the store and when reaching a safe point during the route, try to locate via Points of Interest functionality on GPS.

If I successfully remembered all or part of the name, search the Internet later to obtain the address, then input the address into the GPS.

If time allows, delay driving to my destination and drive to the store, realizing that the store might not be open.

These are the requirements:

Since the user will be driving while initiating this functionality, it is imperative not to break the driver’s concentration—since this could lead to an accident.

Since the user will most likely spot the desired location as he is either quickly approaching it or has just passed it, the functionality must be able to determine and record the car’s current location within 3-5 seconds.

Other requirements that surface

Future scenario.This is a future-based story used to envision one possible way that we could fulfill the targeted user’s goals. I am driving on my way to visit my friend Ed, and I see an interesting-looking antique shop that I would like to check out. Unfortunately, I don’t have the time to stop, because I told Ed that I would be there at precisely 2 p.m. sharp. It would be great if I could just hit a button as I pass the antique shop and the GPS would record the closest street address or nearest intersection. I would like to be able to retrieve that information later and save it in My Favorites.

That brings me to the most important best practice of all: Empty your cup. There is a famous story about a university professor who kept talking about Zen to a Zen master, while the master poured tea until it overflowed. "You are like the cup," the master said to the professor. "You are full to overflowing with opinions and ideas and grand theories. If you are to find what you seek, you must first empty yourself."

And like that professor, you must rid yourself of preconceived ideas and prejudices if you want to truly understand user goals.

]]>
tag:feedblitz.com,2013-06-04:36474/http://feeds.feedblitz.com/~/158957316/0/pragmaticmarketing/articles/requirements/84f40270bcb9631a58dd1f63d7c9cc53http://pragmaticmarketing.com/agility_articles/redirect?id=4203http://feeds.feedblitz.com/~/158958244/0/pragmaticmarketing/articles/requirements~Ways-to-Improve-Customer-CommunicationsHow many times have you built a product, only to find out that nobody was interested in the features you painstakingly included? Even when you asked your customers what they wanted beforehand?

Ultimately, it's not just about talking to your customers that gives you the information you need, it's about talking to them the right way. Here are 20 tips to help you communicate with your customers better, so you can more efficiently deliver the products they actually want—not just what they say they want.

#1 Have Them Tell You How It Would Make Their Lives Better

Customer requests are usually just one or two sentences, devoid of context. How can you possibly gauge the urgency of a request without a real conversation?

Which one of these would you place a higher priority on?

1. "PLEASE add validation checking for email addresses! If you give people a text field to type in their email address, there is nothing stopping them from entering a bunch of junk! This is not a good user experience, if they are expecting us to have their contact info!"

2. "Would it be possible to offer support for text versions of your email notifications? Right now we are only receiving them in HTML."

The first person used the phrase "not a good user experience" with multiple exclamation points, indicating urgency. But when I emailed them to ask how they would benefit from this feature, they talked about how they might want to use our product in the future, if they decided to do a certain marketing campaign. Turns out the requester was just an exclamation-point abuser.

The second person, on the other hand, told me about using our survey product to ask customers about bugs or feature improvements and sending responses directly into their customer support's content management system. The HTML formatting was making the feedback very hard to read and forcing customer support folks to retype long passages every time they wanted to respond. In other words, they were suffering every time they used our product.

We made the change within days. And by learning about how they were using our product, we were able to suggest that same use case to other customers.

#2 Say What Your Product Is For; Say What Your Product Is Against

When I worked at a banking technology company, we maintained a fairly active user forum. There was a handful of users who were openly critical of various features. In particular, they kept requesting very complex power-user features that we knew would appeal to a limited audience and incur a big overall usability cost. We kept not building those features; the users kept getting angrier.

Finally, I posted a message that said:

Look, we are never going to build this feature, and here's why/here's our product vision. We hope you'll stick around as customers, but if you're looking for a power-user product, we may not be the best choice.

I hit "post" and waited for the online fury to begin. But it didn't. It actually made things better. When we didn't share our perspective, customers were forced to assume that we were just ignoring them because we were too stupid or incompetent to build the features they wanted. While we still disagreed, the customers respected that we had a vision ("oh good, you're not idiots after all") and appreciated that we were honest with them.

#3 Have Rules, but Don't Enforce Them

Placing limits on your product has two big potential benefits:

1. Simplifies the user interface to help customers learn it more quickly and thus move to paying you more quickly

2. Enables you to charge more to the subset of customers who need to go beyond those limits

But if you set the wrong limits, it can be a hassle to change your code, change your policies and communicate with all of your users. We have used several "unenforced" limits (how many questions per survey, how many reports, how many events)—where we stated that certain limits existed, but did not actually write the code to enforce them.

If no one breaks your limits, then they are probably too high or too inclusive. If everyone breaks your limits, then they are probably too low. Once you have actual usage data, you can make a much more educated guess on where to set limits, and then write the code to enforce them.

#4 Only Build It If You Can Measure It

To put this tip another way, if you can't think of a way to prove that having done this was good for your business, you probably shouldn't do it. Funnels and metrics are one thing, but product changes fundamentally need to be about revenue.

As a person who cares a lot about design, I always want to redesign/improve bits of whatever product I'm working on. I have to ask myself:

1. Will more people buy the product if you make this change?
2. Will fewer people leave us for a competitor product if you make this change?

And if I can't really, honestly, confidently say "yes" or even "probably" to either of those, it usually means I should suck it up and focus on more important changes.

#5 Tell Them What They Should Do Instead

Customers will often ask for something that is actually bad for them—something that will make your product harder to use or make the results less valuable. You shouldn't build it, but you also shouldn't ignore them.

The right response is to confirm, acknowledge and educate:

It sounds like you want to [get specific question answered/accomplish specific task]. We have seen with other customers that this doesn't work well, because [reasons, consequences]. What may work for you is to [alternate suggestion]. This would help you to do what you're trying to do without [consequence]. Here's how you would get that set up.

Here's an example:

It sounds like you want to maximize the number of responses you get to your question about shipping rates. However, we have seen with our other customers that displaying the same survey repeatedly does not increase the rate of thoughtful responses—in fact, they've gotten customer complaints about the intrusiveness of the survey and more non-useful responses like "make this go away.'"
What may work for you is to ask this question on a more relevant page, such as the shopping-cart page. You will get fewer responses, but they are more likely to be thoughtful, content-rich responses. You'd do this by ...

#6 Fake the Functionality

I had this brilliant idea that our survey product should support automatically recurring surveys—to run a Net Promoter Score survey automatically every month, for example. But building the automation on the back end and the user interface on the front end would have been quite a bit of effort for something I wasn't positive customers would use.

Luckily, "automation" lends itself very well to manual human labor.

I picked two-dozen customers, and sent them individually composed emails (that looked like "real" marketing emails), inviting them to try this recurring survey feature "in beta." For the four who said okay, I logged into their accounts as admin and set up the survey for them. I then waited one month and sent another email saying that a month had passed, and so we were about to run their survey again.

From their perspective, it looked like a true automated recurrence, a feature that they said they wanted to use. But they all emailed back to say: Never mind, I don't really want this. How can I turn it off?

#7 Send Your Customer to Your Competitor

You know your competition, so you probably know about tools that your prospective customers haven't heard of. Sure it's great if it's your product that makes them happy, but you still get partial credit for being the nice person who told them where they should go.

I send people who want to write long-form surveys to a competitor, and a decent number of them have come back months later because we had a good interaction and they're ready to use our services

A good format:

Thanks for wanting to use [ProductName]. Unfortunately, we don't do [feature], but I think you'll be able to do what you need with [CompetitorName]. Their product does [feature], and we've talked to people who are happy with them. In the future, when you need to do [feature that ProductName can handle], we hope you'll come back and check us out again!

#8 Ignore It Until You Can't

My favorite line: "You will have both visionaries and nutcases using your product. It's very hard to tell them apart." In other words, if you jump on a feature request the first time you hear it, you may be taking advice from a nutcase.

Here's what happens. You get a request. Wait. If it's a good one, you will start hearing other people request it soon. Or you can be proactive and casually ask other customers if they have the same problem. (Note: Do not say, "Would you use an automatic cat washer?" Instead, say, "Tell me about how you keep your cat clean." Problem, not solution.) If no one else requests it, and people don't respond when you ask them about the problem, you can safely ignore it.

#9 Offer a Workaround

Useful tip: The people who ask for complicated features are usually the people best equipped to handle a long or tedious workaround. Just recently, a customer asked for a way to exclude certain data from our metrics—something we don't support—but I offered them two potential workaround solutions. Neither was perfect, and both required the customer to write extra code—but they were completely okay with that.

I've heard people say that offering a workaround is like admitting that your product is flawed. Yes, it is. But you still want them to be able to get value out of it. A good format for this:

However, if I understand correctly, you may be able to [briefly describe workaround process] in order to approximate [that thing you want to do]. Here are the step-by-step instructions. Please let me know if this is confusing, or if I am misunderstanding the task you're looking to do.

The advantage is that you can then watch your customers using the workaround and get better ideas on how to eventually build the easier, more "productized" way of doing the same task because you're able to anticipate their needs.

#10 Be Less Attractive (to Certain Types of Customers)

Each type of customer is demanding in a different way: Corporate/mainstream companies may expect faster support turnaround and more custom attention; power users may expect more complex features; and casual consumers may expect greater ease of use and guided onboarding. Try to do all three, and you will stretch yourself too thin and disappoint your customers.

#11 Until We Can Do It, Use Us for Free

As I mentioned, you will have customers who are visionaries. They can see ahead to things that your product should do. This makes them impatient. You may agree with them—but you've seen your schedule and know it's not going to come in the next month, or the one after that.

So you say, "You're right, we should offer Feature X. In fact, I'm also really eager for us to include that, because I know that right now you are doing [workaround] and that's tedious. Unfortunately, we're a small team so I can't promise that it's coming in the next month or two. In the meantime, I've comped your account."

That's my way of saying that I hope they will stick around, and that I hope I can ping them again when we're actually building Feature X.

#12 Let Some Fish Get Away

Related to the previous two, sometimes you will acquire a customer and then realize you're just not going to be able to make this customer happy.

Sometimes they want features that we are never, ever going to build, because they clash with our product vision or will actually hinder our ability to gain customers/monetize. Sometimes it's our fault: We have some weird bug that really only affects them, and so it's not worth devoting a ton of time to fixing it.

In either case, here's what you say:

Unfortunately, we're a small team and are not going to be able to accommodate your request/bug fix. I'm sorry we are not providing you with the great experience we want our customers to have. But I'd rather be honest than keep you waiting, and I've refunded your subscription fee. You may want to check out [Other Site] or [Other Site]; they may be able to better serve you.

I haven't had to do this often, but I've been quite surprised by how well customers took the news the few times I have. I guess the bar for honest communication is so low that even if you give people bad news, they're glad to hear something true vs. something that just sounds good.

#13 Build a Simple Application Program Interface (API)

Here's the thing about configuration and customization options: They make power users happy, but they drive away your mainstream customers by cluttering up your interface and making it harder for them to make decisions.

Our customers kept asking about configuration that fit their specific needs. I loved that they were so enthusiastic about the product as to want to integrate it into their sites, but knew that adding another dozen options to our already-crowded interface would be a disaster.

I can't take credit for the solution, though. Our developer Michael told me, "I got tired of hearing about these requests so I just wrote a quick API. Here's how it works. Customers can write any bit of code around it to control the triggers." This has worked tremendously well, and the customers are more than willing to write the extra code for the extra control they want.

#14 Email Us for More Info

Early on, I saw that several of our paying customers were marketing agencies, using one account to run surveys for several clients. I hypothesized that we could charge more money to agencies, since they were able to get value on multiple sites (and were probably passing the costs along to their clients).

I tested that hypothesis by adding a single "email us" line to our pricing page. I figured that would give me the contacts necessary to do customer development on this segment. But to date, almost no one has emailed about agency pricing. No one cares enough. So not only did we save hours of coding, we even saved hours of customer development interviews!

#15 Force Customers to Pick a Single Priority

I've actually used this more as an internal tool. Let's say you have a bunch of new features you want to build, a bunch of bugs that need fixing and some existing features that should be improved. Your CEO says, "It's all important. We should be working on all of this." (This has been the case with every CEO I've ever worked with.)

So you say, "Here are five choices. If you could only have ONE, because all of our engineers were stranded on a deserted island and could only send us code via messages in a bottle, which ONE would it be?" (Or make up your own story, the funnier the better.)

Then that becomes priority No. 1. Repeat with the remaining items, and thus avoid the "everything is highest priority" syndrome—at least a little bit.

#16 Charge a Ridiculous Amount

Usually, if a customer requests something that you don't want to build or that doesn't fit with your vision, you can simply offer to charge them an insane amount of money and they will suddenly reevaluate their priorities and decide it's not necessary after all.

But if they don't come to that decision, that's a signal you should pay attention.

At one company, we had a customer who demanded very extensive changes for Americans with Disabilities Act (ADA) compliance. Saying "no" wasn't an option if we wanted to keep the customer, but charging what seemed like a ridiculous amount of money was. Surprisingly, they said yes.

Actually making those changes was incredibly painful and tedious, but it brought to my attention that the capability was worth way more than we hypothesized.

I worked with other product managers to ensure that our requirements included ADA specifications in future releases, and I worked with engineers so they could make certain parts of the code more modular for easier changes in the future. (And we were still able to charge a boatload of money every time someone requested these features.)

#17 and #18 Ask for Help. And Be Grateful

If people are getting enough value from your product, they are probably willing to contribute some effort to make it even better. But let's not be totally arrogant here. My customers certainly aren't walking around all day thinking, "How can I make Cindy's product better?" It doesn't occur to them, unless you ask.

When the first person emailed to ask if we could provide our survey templates in Spanish, I knew our software would handle the character display. But we didn't have the language expertise in-house. And for a fledgling product, I couldn't justify hiring contractors. So I said, "Well, if you're willing to provide translations, we'll make them available."

The first guy responded with a three-page document of translated questions. So I set up a quick web page with forms that made it easy to collect line-by-line translations. It also included these instructions: Please feel free to rephrase if any of these questions or answers don't directly translate well.

We tweeted about how awesome it was to get translations and sent effusive thank-you emails out. This created a virtuous cycle: More people volunteering to translate, more thanks, more volunteers, etc. We now have surveys available in 14 languages and a significant non-English-speaking customer base.

#19 Notify Me When …

The feature doesn't exist yet. You put up a checkbox to "notify me when it exists." This isn't always a literal checkbox, but it's some way of prompting your audience to respond (or not).

The month before we initially launched, we put up a "notify me" splash page. When you clicked the "notify me" checkbox, you were taken to a brief survey. This confirmed customer interest, gave us a ton of email addresses and filled in an initial customer profile, so I could contact people for customer development interviews. Instead of completely losing that potential customer, we had another opportunity to win them over if/when we added the feature.

#20 Play Nice with Others

Your customers want to solve their problems. If your product doesn't do it all, figure out which additional products you can work with to get the job done.

Customers frequently ask if we're going to build a long-form survey platform to complement our current offering. We're not, but we found that using our tiny survey as a hook was a really efficient way to get people into a long survey. So I wrote up a quick guide showing people how to use our offering together with another company's.

While a formal integration would be nice, a detailed checklist is a good workaround in the short term. The rarest currency in most companies is time, and the biggest risk to time is the uncertainty of having to figure stuff out. A checklist or screencast doesn't reduce the amount of steps, but it dramatically reduces the number of decisions and "figure-it-outs"—and that makes customers happy.

Communicate to Win

All of these tips are about communicating with the market—talking and listening to current or potential customers.

When your product/company seeks to solve painful problems for customers through these communications, you create better relationships. You're empowered to ask more questions, and customers are happy to provide you with information in the hopes that it will further diminish their pains.

And whether you do it yourself, through offering competitor info or building partnerships, what you're providing is more likely to go beyond what customers say and addresses what they actually do—and they'll turn to you next time as their go-to resource.

]]>
Thu, 17 Jan 2013 00:00:00 -0400How many times have you built a product, only to find out that nobody was interested in the features you painstakingly included? Even when you asked your customers what they wanted beforehand?

Ultimately, it's not just about talking to your customers that gives you the information you need, it's about talking to them the right way. Here are 20 tips to help you communicate with your customers better, so you can more efficiently deliver the products they actually want—not just what they say they want.

#1 Have Them Tell You How It Would Make Their Lives Better

Customer requests are usually just one or two sentences, devoid of context. How can you possibly gauge the urgency of a request without a real conversation?

Which one of these would you place a higher priority on?

1. "PLEASE add validation checking for email addresses! If you give people a text field to type in their email address, there is nothing stopping them from entering a bunch of junk! This is not a good user experience, if they are expecting us to have their contact info!"

2. "Would it be possible to offer support for text versions of your email notifications? Right now we are only receiving them in HTML."

The first person used the phrase "not a good user experience" with multiple exclamation points, indicating urgency. But when I emailed them to ask how they would benefit from this feature, they talked about how they might want to use our product in the future, if they decided to do a certain marketing campaign. Turns out the requester was just an exclamation-point abuser.

The second person, on the other hand, told me about using our survey product to ask customers about bugs or feature improvements and sending responses directly into their customer support's content management system. The HTML formatting was making the feedback very hard to read and forcing customer support folks to retype long passages every time they wanted to respond. In other words, they were suffering every time they used our product.

We made the change within days. And by learning about how they were using our product, we were able to suggest that same use case to other customers.

#2 Say What Your Product Is For; Say What Your Product Is Against

When I worked at a banking technology company, we maintained a fairly active user forum. There was a handful of users who were openly critical of various features. In particular, they kept requesting very complex power-user features that we knew would appeal to a limited audience and incur a big overall usability cost. We kept not building those features; the users kept getting angrier.

Finally, I posted a message that said:

Look, we are never going to build this feature, and here's why/here's our product vision. We hope you'll stick around as customers, but if you're looking for a power-user product, we may not be the best choice.

I hit "post" and waited for the online fury to begin. But it didn't. It actually made things better. When we didn't share our perspective, customers were forced to assume that we were just ignoring them because we were too stupid or incompetent to build the features they wanted. While we still disagreed, the customers respected that we had a vision ("oh good, you're not idiots after all") and appreciated that we were honest with them.

#3 Have Rules, but Don't Enforce Them

Placing limits on your product has two big potential benefits:

1. Simplifies the user interface to help customers learn it more quickly and thus move to paying you more quickly

2. Enables you to charge more to the subset of customers who need to go beyond those limits

But if you set the wrong limits, it can be a hassle to change your code, change your policies and communicate with all of your users. We have used several "unenforced" limits (how many questions per survey, how many reports, how many events)—where we stated that certain limits existed, but did not actually write the code to enforce them.

If no one breaks your limits, then they are probably too high or too inclusive. If everyone breaks your limits, then they are probably too low. Once you have actual usage data, you can make a much more educated guess on where to set limits, and then write the code to enforce them.

#4 Only Build It If You Can Measure It

To put this tip another way, if you can't think of a way to prove that having done this was good for your business, you probably shouldn't do it. Funnels and metrics are one thing, but product changes fundamentally need to be about revenue.

As a person who cares a lot about design, I always want to redesign/improve bits of whatever product I'm working on. I have to ask myself:

1. Will more people buy the product if you make this change?
2. Will fewer people leave us for a competitor product if you make this change?

And if I can't really, honestly, confidently say "yes" or even "probably" to either of those, it usually means I should suck it up and focus on more important changes.

#5 Tell Them What They Should Do Instead

Customers will often ask for something that is actually bad for them—something that will make your product harder to use or make the results less valuable. You shouldn't build it, but you also shouldn't ignore them.

The right response is to confirm, acknowledge and educate:

It sounds like you want to [get specific question answered/accomplish specific task]. We have seen with other customers that this doesn't work well, because [reasons, consequences]. What may work for you is to [alternate suggestion]. This would help you to do what you're trying to do without [consequence]. Here's how you would get that set up.

Here's an example:

It sounds like you want to maximize the number of responses you get to your question about shipping rates. However, we have seen with our other customers that displaying the same survey repeatedly does not increase the rate of thoughtful responses—in fact, they've gotten customer complaints about the intrusiveness of the survey and more non-useful responses like "make this go away.'"
What may work for you is to ask this question on a more relevant page, such as the shopping-cart page. You will get fewer responses, but they are more likely to be thoughtful, content-rich responses. You'd do this by ...

#6 Fake the Functionality

I had this brilliant idea that our survey product should support automatically recurring surveys—to run a Net Promoter Score survey automatically every month, for example. But building the automation on the back end and the user interface on the front end would have been quite a bit of effort for something I wasn't positive customers would use.

Luckily, "automation" lends itself very well to manual human labor.

I picked two-dozen customers, and sent them individually composed emails (that looked like "real" marketing emails), inviting them to try this recurring survey feature "in beta." For the four who said okay, I logged into their accounts as admin and set up the survey for them. I then waited one month and sent another email saying that a month had passed, and so we were about to run their survey again.

From their perspective, it looked like a true automated recurrence, a feature that they said they wanted to use. But they all emailed back to say: Never mind, I don't really want this. How can I turn it off?

#7 Send Your Customer to Your Competitor

You know your competition, so you probably know about tools that your prospective customers haven't heard of. Sure it's great if it's your product that makes them happy, but you still get partial credit for being the nice person who told them where they should go.

I send people who want to write long-form surveys to a competitor, and a decent number of them have come back months later because we had a good interaction and they're ready to use our services

A good format:

Thanks for wanting to use [ProductName]. Unfortunately, we don't do [feature], but I think you'll be able to do what you need with [CompetitorName]. Their product does [feature], and we've talked to people who are happy with them. In the future, when you need to do [feature that ProductName can handle], we hope you'll come back and check us out again!

#8 Ignore It Until You Can't

My favorite line: "You will have both visionaries and nutcases using your product. It's very hard to tell them apart." In other words, if you jump on a feature request the first time you hear it, you may be taking advice from a nutcase.

Here's what happens. You get a request. Wait. If it's a good one, you will start hearing other people request it soon. Or you can be proactive and casually ask other customers if they have the same problem. (Note: Do not say, "Would you use an automatic cat washer?" Instead, say, "Tell me about how you keep your cat clean." Problem, not solution.) If no one else requests it, and people don't respond when you ask them about the problem, you can safely ignore it.

#9 Offer a Workaround

Useful tip: The people who ask for complicated features are usually the people best equipped to handle a long or tedious workaround. Just recently, a customer asked for a way to exclude certain data from our metrics—something we don't support—but I offered them two potential workaround solutions. Neither was perfect, and both required the customer to write extra code—but they were completely okay with that.

I've heard people say that offering a workaround is like admitting that your product is flawed. Yes, it is. But you still want them to be able to get value out of it. A good format for this:

However, if I understand correctly, you may be able to [briefly describe workaround process] in order to approximate [that thing you want to do]. Here are the step-by-step instructions. Please let me know if this is confusing, or if I am misunderstanding the task you're looking to do.

The advantage is that you can then watch your customers using the workaround and get better ideas on how to eventually build the easier, more "productized" way of doing the same task because you're able to anticipate their needs.

#10 Be Less Attractive (to Certain Types of Customers)

Each type of customer is demanding in a different way: Corporate/mainstream companies may expect faster support turnaround and more custom attention; power users may expect more complex features; and casual consumers may expect greater ease of use and guided onboarding. Try to do all three, and you will stretch yourself too thin and disappoint your customers.

#11 Until We Can Do It, Use Us for Free

As I mentioned, you will have customers who are visionaries. They can see ahead to things that your product should do. This makes them impatient. You may agree with them—but you've seen your schedule and know it's not going to come in the next month, or the one after that.

So you say, "You're right, we should offer Feature X. In fact, I'm also really eager for us to include that, because I know that right now you are doing [workaround] and that's tedious. Unfortunately, we're a small team so I can't promise that it's coming in the next month or two. In the meantime, I've comped your account."

That's my way of saying that I hope they will stick around, and that I hope I can ping them again when we're actually building Feature X.

#12 Let Some Fish Get Away

Related to the previous two, sometimes you will acquire a customer and then realize you're just not going to be able to make this customer happy.

Sometimes they want features that we are never, ever going to build, because they clash with our product vision or will actually hinder our ability to gain customers/monetize. Sometimes it's our fault: We have some weird bug that really only affects them, and so it's not worth devoting a ton of time to fixing it.

In either case, here's what you say:

Unfortunately, we're a small team and are not going to be able to accommodate your request/bug fix. I'm sorry we are not providing you with the great experience we want our customers to have. But I'd rather be honest than keep you waiting, and I've refunded your subscription fee. You may want to check out [Other Site] or [Other Site]; they may be able to better serve you.

I haven't had to do this often, but I've been quite surprised by how well customers took the news the few times I have. I guess the bar for honest communication is so low that even if you give people bad news, they're glad to hear something true vs. something that just sounds good.

#13 Build a Simple Application Program Interface (API)

Here's the thing about configuration and customization options: They make power users happy, but they drive away your mainstream customers by cluttering up your interface and making it harder for them to make decisions.

Our customers kept asking about configuration that fit their specific needs. I loved that they were so enthusiastic about the product as to want to integrate it into their sites, but knew that adding another dozen options to our already-crowded interface would be a disaster.

I can't take credit for the solution, though. Our developer Michael told me, "I got tired of hearing about these requests so I just wrote a quick API. Here's how it works. Customers can write any bit of code around it to control the triggers." This has worked tremendously well, and the customers are more than willing to write the extra code for the extra control they want.

#14 Email Us for More Info

Early on, I saw that several of our paying customers were marketing agencies, using one account to run surveys for several clients. I hypothesized that we could charge more money to agencies, since they were able to get value on multiple sites (and were probably passing the costs along to their clients).

I tested that hypothesis by adding a single "email us" line to our pricing page. I figured that would give me the contacts necessary to do customer development on this segment. But to date, almost no one has emailed about agency pricing. No one cares enough. So not only did we save hours of coding, we even saved hours of customer development interviews!

#15 Force Customers to Pick a Single Priority

I've actually used this more as an internal tool. Let's say you have a bunch of new features you want to build, a bunch of bugs that need fixing and some existing features that should be improved. Your CEO says, "It's all important. We should be working on all of this." (This has been the case with every CEO I've ever worked with.)

So you say, "Here are five choices. If you could only have ONE, because all of our engineers were stranded on a deserted island and could only send us code via messages in a bottle, which ONE would it be?" (Or make up your own story, the funnier the better.)

Then that becomes priority No. 1. Repeat with the remaining items, and thus avoid the "everything is highest priority" syndrome—at least a little bit.

#16 Charge a Ridiculous Amount

Usually, if a customer requests something that you don't want to build or that doesn't fit with your vision, you can simply offer to charge them an insane amount of money and they will suddenly reevaluate their priorities and decide it's not necessary after all.

But if they don't come to that decision, that's a signal you should pay attention.

At one company, we had a customer who demanded very extensive changes for Americans with Disabilities Act (ADA) compliance. Saying "no" wasn't an option if we wanted to keep the customer, but charging what seemed like a ridiculous amount of money was. Surprisingly, they said yes.

Actually making those changes was incredibly painful and tedious, but it brought to my attention that the capability was worth way more than we hypothesized.

I worked with other product managers to ensure that our requirements included ADA specifications in future releases, and I worked with engineers so they could make certain parts of the code more modular for easier changes in the future. (And we were still able to charge a boatload of money every time someone requested these features.)

#17 and #18 Ask for Help. And Be Grateful

If people are getting enough value from your product, they are probably willing to contribute some effort to make it even better. But let's not be totally arrogant here. My customers certainly aren't walking around all day thinking, "How can I make Cindy's product better?" It doesn't occur to them, unless you ask.

When the first person emailed to ask if we could provide our survey templates in Spanish, I knew our software would handle the character display. But we didn't have the language expertise in-house. And for a fledgling product, I couldn't justify hiring contractors. So I said, "Well, if you're willing to provide translations, we'll make them available."

The first guy responded with a three-page document of translated questions. So I set up a quick web page with forms that made it easy to collect line-by-line translations. It also included these instructions: Please feel free to rephrase if any of these questions or answers don't directly translate well.

We tweeted about how awesome it was to get translations and sent effusive thank-you emails out. This created a virtuous cycle: More people volunteering to translate, more thanks, more volunteers, etc. We now have surveys available in 14 languages and a significant non-English-speaking customer base.

#19 Notify Me When …

The feature doesn't exist yet. You put up a checkbox to "notify me when it exists." This isn't always a literal checkbox, but it's some way of prompting your audience to respond (or not).

The month before we initially launched, we put up a "notify me" splash page. When you clicked the "notify me" checkbox, you were taken to a brief survey. This confirmed customer interest, gave us a ton of email addresses and filled in an initial customer profile, so I could contact people for customer development interviews. Instead of completely losing that potential customer, we had another opportunity to win them over if/when we added the feature.

#20 Play Nice with Others

Your customers want to solve their problems. If your product doesn't do it all, figure out which additional products you can work with to get the job done.

Customers frequently ask if we're going to build a long-form survey platform to complement our current offering. We're not, but we found that using our tiny survey as a hook was a really efficient way to get people into a long survey. So I wrote up a quick guide showing people how to use our offering together with another company's.

While a formal integration would be nice, a detailed checklist is a good workaround in the short term. The rarest currency in most companies is time, and the biggest risk to time is the uncertainty of having to figure stuff out. A checklist or screencast doesn't reduce the amount of steps, but it dramatically reduces the number of decisions and "figure-it-outs"—and that makes customers happy.

Communicate to Win

All of these tips are about communicating with the market—talking and listening to current or potential customers.

When your product/company seeks to solve painful problems for customers through these communications, you create better relationships. You're empowered to ask more questions, and customers are happy to provide you with information in the hopes that it will further diminish their pains.

And whether you do it yourself, through offering competitor info or building partnerships, what you're providing is more likely to go beyond what customers say and addresses what they actually do—and they'll turn to you next time as their go-to resource.

Good product managers observe untapped situations in the market, form an accurate understanding of problems tied to those observations and reframe them in a requirement that makes sense to those who craft the solution.

To be properly understood, the requirement must provide all the materials necessary for a solution to be created, including the user type, the desired end result and the success measure.

A few common missteps of requirement writing, however, can mean ineffective communications that can lead to large increases in the overall time and money invested in the project. And what should be avoided is just as important to consider as what should be included.

Here are five pitfalls to avoid in order to lessen the gap between requirements and the final product.

1. Not Knowing the Audience

Marketers know that without tailoring their messaging to a target audience, they have little chance of gaining the valuable attention they seek. This is also true for product managers and their requirements documents. In most software shops, the audience is the developers, but is your documentation tailored around that target audience?

Does the writing style take into account personality styles and differing methods of comprehension? For example, does your audience contain visual learners? If yes, do you include graphics in your requirements?

Let's take a look at a fictitious developer, Bob. One could gather the following behaviors by observing Bob at work, asking about his preferences or observing the style of his own documentation. Here is a fabricated list of personality qualities that correspond to Bob:

Likes to work autonomously

Very absorbed in his work

Highly creative

Exceptionally logical

Eye for detail

Strong conviction to own work

Unconcerned with diplomacy

These characteristics can lead to a document tailored so that Bob can effectively deliver on those requirements:

Order and structure. Make the document appeal to his logical side with an inclusion of concise details.

Time to read and absorb the request. Respect his autonomy and give him enough time to consume, digest and question. Often, the best responses to a document are those given three days after providing the information. Increased ownership of solutions or specifications will occur if the developer has had the time to properly formulate his solution to the requirements.

Concise, Clear Documentation. Provide a full understanding of the problem, the user and the context. Bob can then make an easier assessment of the work ahead to create the solution. Use of “the product shall” statements can help provide additional clarity.

Hard dates for functional specification completion. Providing this, along with other milestones, helps goals to be set and measured.

While these points may differ from your own requirements audience, it does bring attention to the fact that adapting to a certain learning style can drive the quality of the product with less effort—and keep Bob happier too.

2. Ambiguity

This is one of the most difficult obstacles to overcome when writing requirements. Somewhere in the middle of a design-free requirement and a functional specification is a middle point where product management ends and development begins. It’s the moment when a problem becomes a solution. In order for that transition to occur, product management must ensure that all information is provided to understand the background, intent and prioritization of a requirement. While time consuming, a good product manager will be able to justify and/or provide valid business cases for every requirement.

Natural language is prone to ambiguity, which makes the formality of the requirements document much more important. If worded correctly, multiple readers of a requirement should ultimately come to a nearly identical interpretation. Avoiding subjective words—such as “quickly,” “maximize” or “user-friendly”—will reduce the likelihood of interpretation shift.

The most effective way to avoid ambiguity is to complement the requirement with a host of user stories or use scenarios. By providing a detailed list of user stories, the developer can easily understand the intended use of the product. The software developer might have very little work experience in the target market for which the product is intended, but having insight into how a customer would potentially use a feature helps compensate for that lack of understanding.

3. Squeezing a Solution into the Problem

How many times have you seen (or written) a requirement containing a solution for the design? It really doesn’t take much: a short reference to what the interface should look like, or a reference to where the solution should be. Adding the “how” to the “what” will be met with disdain by the developer, who believes the product manager is treading on his turf with that type of information. Ultimately, it does belong to the development side of the house.

Product managers, although well-intentioned, tend to be a “do-it-yourself” type of crowd. It seems natural to include the solution with the requirement, to alleviate the underlying concern that it will be translated incorrectly.

This good intention may cut into the developer’s creativity to solve the problem. A better method is to check for gaps between the description of the problem (the requirement) and the plan for the solution (normally the functional specification). It only makes sense that the observer of the problem verifies and possibly has final acceptance over the functional specification. This ensures the plan for the solution is valid and on track with the requirement before the work begins.

4. Not Making Form Follow Function

The “form follows function” concept from modern architecture also holds weight in the world of product management. The requirement itself must follow strict adherence to grammatical form. Writing errors reduce the perceived importance of the requirement and distract the reader away from the essence of the requirement. Let’s face it: Importance aside, requirement documents are not the most exciting things to read. Add in poor spelling and grammatical errors and you will see the reader’s level of interest plummet.

Additionally, providing a structured document, complete with full numeration of all requirements, improves the ease of collaboration. The ability to identify a requirement easily facilitates discussion and related queries. Furthermore, numeration of the requirements also makes them traceable. In fact, it is a good practice for requirements documents to include a version number, list of stakeholders, ownership change log, revision history, summary and prioritization to ensure effective administration of the document and support for the content.

5. Not Having a Holistic Approach

Requirements that do not hit the mark and fail to sell in the market do so because the feature was not conceived with the full customer experience in mind. Take the customer point of view a step further in your mental image of their imagined use of your product. Sure the customer can install product X and use it, but what if they want to do something else with that feature? What if they uninstalled it or forgot to configure it correctly or didn’t read the manual or wanted to look for online help? How would the customer use your product if they were rushed and only have 10 minutes before running to pick up the kids? What if they used your product with limited focus or enthusiasm? Would the experience be different? Put aside the logical experience and consider any possible external factors or influences on your product.

Cause and effect can also lead to issues. In product management, it can be easy to fix a symptom (effect) and not deal with the cause. Take, for example, a software console that performs tasks on workstations. Customers begin to complain that when they launch a task on the workstation, the system just hangs. Being a good product manager, you find out from technical support that the console does not hang, it is simply busy doing a system task that is not viewable by the user. Since not much can be done with that, you decide to make the system task fully visible to the user so they know what is going on at all times.

You go home early, content in the knowledge that the improved disclosure keeps customers informed and happy. But hold on! Customers still hate your console, because the system tasks keep blocking their own tasks from launching. In this case, the task-processing design was ineffective but was never identified as the root of the problem. You fixed the effect and not the cause. Thus an evaluation of any corrective measure is needed to determine if the root cause has been addressed properly.

Getting It Right

Great requirements lead to effective and cost-efficient planning of the development process. In order to ensure the best transfer of information from market to product, product management needs to document the requirements in ways that accurately define the needs of the market and allow for development creativity. By ensuring you know your audience and avoiding the other pitfalls of requirement writing, you can provide all the building blocks necessary to build the best solutions for your market.

]]>
Mon, 22 Oct 2012 00:00:00 -0400

Good product managers observe untapped situations in the market, form an accurate understanding of problems tied to those observations and reframe them in a requirement that makes sense to those who craft the solution.

To be properly understood, the requirement must provide all the materials necessary for a solution to be created, including the user type, the desired end result and the success measure.

A few common missteps of requirement writing, however, can mean ineffective communications that can lead to large increases in the overall time and money invested in the project. And what should be avoided is just as important to consider as what should be included.

Here are five pitfalls to avoid in order to lessen the gap between requirements and the final product.

1. Not Knowing the Audience

Marketers know that without tailoring their messaging to a target audience, they have little chance of gaining the valuable attention they seek. This is also true for product managers and their requirements documents. In most software shops, the audience is the developers, but is your documentation tailored around that target audience?

Does the writing style take into account personality styles and differing methods of comprehension? For example, does your audience contain visual learners? If yes, do you include graphics in your requirements?

Let's take a look at a fictitious developer, Bob. One could gather the following behaviors by observing Bob at work, asking about his preferences or observing the style of his own documentation. Here is a fabricated list of personality qualities that correspond to Bob:

Likes to work autonomously

Very absorbed in his work

Highly creative

Exceptionally logical

Eye for detail

Strong conviction to own work

Unconcerned with diplomacy

These characteristics can lead to a document tailored so that Bob can effectively deliver on those requirements:

Order and structure. Make the document appeal to his logical side with an inclusion of concise details.

Time to read and absorb the request. Respect his autonomy and give him enough time to consume, digest and question. Often, the best responses to a document are those given three days after providing the information. Increased ownership of solutions or specifications will occur if the developer has had the time to properly formulate his solution to the requirements.

Concise, Clear Documentation. Provide a full understanding of the problem, the user and the context. Bob can then make an easier assessment of the work ahead to create the solution. Use of “the product shall” statements can help provide additional clarity.

Hard dates for functional specification completion. Providing this, along with other milestones, helps goals to be set and measured.

While these points may differ from your own requirements audience, it does bring attention to the fact that adapting to a certain learning style can drive the quality of the product with less effort—and keep Bob happier too.

2. Ambiguity

This is one of the most difficult obstacles to overcome when writing requirements. Somewhere in the middle of a design-free requirement and a functional specification is a middle point where product management ends and development begins. It’s the moment when a problem becomes a solution. In order for that transition to occur, product management must ensure that all information is provided to understand the background, intent and prioritization of a requirement. While time consuming, a good product manager will be able to justify and/or provide valid business cases for every requirement.

Natural language is prone to ambiguity, which makes the formality of the requirements document much more important. If worded correctly, multiple readers of a requirement should ultimately come to a nearly identical interpretation. Avoiding subjective words—such as “quickly,” “maximize” or “user-friendly”—will reduce the likelihood of interpretation shift.

The most effective way to avoid ambiguity is to complement the requirement with a host of user stories or use scenarios. By providing a detailed list of user stories, the developer can easily understand the intended use of the product. The software developer might have very little work experience in the target market for which the product is intended, but having insight into how a customer would potentially use a feature helps compensate for that lack of understanding.

3. Squeezing a Solution into the Problem

How many times have you seen (or written) a requirement containing a solution for the design? It really doesn’t take much: a short reference to what the interface should look like, or a reference to where the solution should be. Adding the “how” to the “what” will be met with disdain by the developer, who believes the product manager is treading on his turf with that type of information. Ultimately, it does belong to the development side of the house.

Product managers, although well-intentioned, tend to be a “do-it-yourself” type of crowd. It seems natural to include the solution with the requirement, to alleviate the underlying concern that it will be translated incorrectly.

This good intention may cut into the developer’s creativity to solve the problem. A better method is to check for gaps between the description of the problem (the requirement) and the plan for the solution (normally the functional specification). It only makes sense that the observer of the problem verifies and possibly has final acceptance over the functional specification. This ensures the plan for the solution is valid and on track with the requirement before the work begins.

4. Not Making Form Follow Function

The “form follows function” concept from modern architecture also holds weight in the world of product management. The requirement itself must follow strict adherence to grammatical form. Writing errors reduce the perceived importance of the requirement and distract the reader away from the essence of the requirement. Let’s face it: Importance aside, requirement documents are not the most exciting things to read. Add in poor spelling and grammatical errors and you will see the reader’s level of interest plummet.

Additionally, providing a structured document, complete with full numeration of all requirements, improves the ease of collaboration. The ability to identify a requirement easily facilitates discussion and related queries. Furthermore, numeration of the requirements also makes them traceable. In fact, it is a good practice for requirements documents to include a version number, list of stakeholders, ownership change log, revision history, summary and prioritization to ensure effective administration of the document and support for the content.

5. Not Having a Holistic Approach

Requirements that do not hit the mark and fail to sell in the market do so because the feature was not conceived with the full customer experience in mind. Take the customer point of view a step further in your mental image of their imagined use of your product. Sure the customer can install product X and use it, but what if they want to do something else with that feature? What if they uninstalled it or forgot to configure it correctly or didn’t read the manual or wanted to look for online help? How would the customer use your product if they were rushed and only have 10 minutes before running to pick up the kids? What if they used your product with limited focus or enthusiasm? Would the experience be different? Put aside the logical experience and consider any possible external factors or influences on your product.

Cause and effect can also lead to issues. In product management, it can be easy to fix a symptom (effect) and not deal with the cause. Take, for example, a software console that performs tasks on workstations. Customers begin to complain that when they launch a task on the workstation, the system just hangs. Being a good product manager, you find out from technical support that the console does not hang, it is simply busy doing a system task that is not viewable by the user. Since not much can be done with that, you decide to make the system task fully visible to the user so they know what is going on at all times.

You go home early, content in the knowledge that the improved disclosure keeps customers informed and happy. But hold on! Customers still hate your console, because the system tasks keep blocking their own tasks from launching. In this case, the task-processing design was ineffective but was never identified as the root of the problem. You fixed the effect and not the cause. Thus an evaluation of any corrective measure is needed to determine if the root cause has been addressed properly.

Getting It Right

Great requirements lead to effective and cost-efficient planning of the development process. In order to ensure the best transfer of information from market to product, product management needs to document the requirements in ways that accurately define the needs of the market and allow for development creativity. By ensuring you know your audience and avoiding the other pitfalls of requirement writing, you can provide all the building blocks necessary to build the best solutions for your market.

]]>
tag:feedblitz.com,2012-10-22:36474/http://feeds.feedblitz.com/~/158958250/0/pragmaticmarketing/articles/requirements/2e9d9ac399291c6c55a84a67b2ece041http://pragmaticmarketing.com/agility_articles/redirect?id=4170http://feeds.feedblitz.com/~/158958258/0/pragmaticmarketing/articles/requirements~Cut-Features-Add-ValueThe concept of a “minimum viable product” is commonly used in the startup world to identify the subset of features needed to deploy a usable product and test it in the market. Yet 65 percent of features in software aren’t used (according to a Standish Group survey), and those unused and rarely used features are everywhere you look.

Product managers and business analysts are in the unique position of being able to drastically cut scope to deliver more usable products faster and for less cost. Some use intuition as their primary approach for understanding the minimum set of features that a product should have. This is, however, neither practical nor scalable. Instead, we need an approach to logically cut unneeded features, so that we implement only the features that deliver the most value.

The key to systematically being able to cut product scope, while still delivering a great product, is to link the value the user needs to receive to the actual features in the product. To understand that value, consider what problems the product is solving and what objectives the user has for the product. This will help you derive the most valuable features.

Ease of access to these features (usability) is also vitally important. You can have all the right features, but if users can’t find them or don’t understand how they work, they won’t use them or your product.

You can use a variety of objectives, people, systems and data requirements models to help link the user’s value to features and increase usability.

Objectives

You can apply a “business objectives model” to understand the user’s desired value. First, make sure you have a grasp of the problem the user needs to solve with the product, then identify what successfully solving that problem would mean for the user—thereby defining an objective for the product. You can then determine whether there is a clear strategy to develop features to meet the objective, or if you should continue to identify relevant lower-level user problems and objectives until you can identify features that can clearly be linked to the objectives.

For example, a team building a new mobile music player for the athletic market should talk to athletes to understand what they need. In Figure 1, notice that the first set of problems and objectives doesn’t tell us very much to help us determine specific features. In fact, we might implement a video screen or a book-reading interface based on the first problem and objective. But when we dig deeper, we might find those features don’t add value for this set of users.Figure 1. An Example Business Objective Model

Remember, we want to cut the features that provide the least value. “Objective chains” help you compare the dollar values to make that determination by comparing the relative order of magnitude value of features. You select the highest-value features, consider their costs and focus the team’s efforts on the biggest return. In our example, if you are developing software for the music player, you could compare features such as continuous play, playlists, sharing songs with friends, import, export and album covers. You can estimate the value of each of these features, considering how many users would likely buy (or not buy) the mobile player based on having the feature or not. If the potential value of the product sales is $10 million and you choose not to build the expected continuous play feature, your sales might drop to zero—therefore you can say that feature is a $10 million feature. Meanwhile, showing album covers on the music player might only be useful to a small subset of the users, so maybe it’s a $10,000 feature

Process Flows

After understanding the features, it’s equally important to think about how the user will experience the functionality step by step. “Process flows” can be created to show this, by thinking about what the user is trying to do (what the initial problem is they are solving) at each step and describing the flow in that manner. The flows should be based on how the user will receive value, not how they access specific functions in the product. If a user just bought the music player, the first step in the flow is to open the box. Then what? The flow should have a very short path to get their old music onto the new device. Keep in mind that different types of users might have different problems to be solved and different expectations, so there might be different process flows for different personas.

It is important to think about product usability, since we not only must implement features that add value for the users, we need to implement them in a way that meets users’ needs so they will adopt the products. You can use the process flows to improve the usability of the product. Consider how many steps a user has to go through to receive the desired value from a feature, and try to reduce those.

In our mobile music example, a user opening the box shouldn’t face a long setup process including settings they won’t use immediately, until finally (and frustratingly) they can at last play music—but they have none loaded. We want them to get to a basic set of functionality right out of the box and worry about other features later.

Requirements Mapping Matrix

The process flows can also be used to identify specific requirements and business rules that are needed to support the in-scope features. And by organizing your requirements by process flow steps in a “requirements mapping matrix” (RMM), you are able to later understand the impact of cutting a feature or changing the user’s flow to access it. An RMM provides “traceablity” and the ability to demonstrate completeness. It is like a traceability matrix, but allows more mappings at once—such as mapping user’s objective to process flow steps to requirements and business rules. Figure 2 shows an example of an RMM.

Figure 2. An Example Requirements Mapping Matrix

Using an RMM, you can also tie these models and the individual requirements back to the user’s original objectives. As you add requirements, you can verify they contribute to the user’s overall objectives. As you cut requirements, you can ensure that they are safe to cut and that the processes they support can still be executed.

Models to Identify the Minimum Viable Product

There are a few basic requirements models that can be applied easily and immediately to any product development effort. The intent is not to propose that you create a lot of useless requirements documentation. Instead, if you select the right models, you can ensure you cut scope and only work on requirements documentation for the needed features. All the while, you are creating a more successful product that will have only the features the user actually needs—and you will have delivered it for less.

]]>
Mon, 22 Oct 2012 00:00:00 -0400The concept of a “minimum viable product” is commonly used in the startup world to identify the subset of features needed to deploy a usable product and test it in the market. Yet 65 percent of features in software aren’t used (according to a Standish Group survey), and those unused and rarely used features are everywhere you look.

Product managers and business analysts are in the unique position of being able to drastically cut scope to deliver more usable products faster and for less cost. Some use intuition as their primary approach for understanding the minimum set of features that a product should have. This is, however, neither practical nor scalable. Instead, we need an approach to logically cut unneeded features, so that we implement only the features that deliver the most value.

The key to systematically being able to cut product scope, while still delivering a great product, is to link the value the user needs to receive to the actual features in the product. To understand that value, consider what problems the product is solving and what objectives the user has for the product. This will help you derive the most valuable features.

Ease of access to these features (usability) is also vitally important. You can have all the right features, but if users can’t find them or don’t understand how they work, they won’t use them or your product.

You can use a variety of objectives, people, systems and data requirements models to help link the user’s value to features and increase usability.

Objectives

You can apply a “business objectives model” to understand the user’s desired value. First, make sure you have a grasp of the problem the user needs to solve with the product, then identify what successfully solving that problem would mean for the user—thereby defining an objective for the product. You can then determine whether there is a clear strategy to develop features to meet the objective, or if you should continue to identify relevant lower-level user problems and objectives until you can identify features that can clearly be linked to the objectives.

For example, a team building a new mobile music player for the athletic market should talk to athletes to understand what they need. In Figure 1, notice that the first set of problems and objectives doesn’t tell us very much to help us determine specific features. In fact, we might implement a video screen or a book-reading interface based on the first problem and objective. But when we dig deeper, we might find those features don’t add value for this set of users.Figure 1. An Example Business Objective Model

Remember, we want to cut the features that provide the least value. “Objective chains” help you compare the dollar values to make that determination by comparing the relative order of magnitude value of features. You select the highest-value features, consider their costs and focus the team’s efforts on the biggest return. In our example, if you are developing software for the music player, you could compare features such as continuous play, playlists, sharing songs with friends, import, export and album covers. You can estimate the value of each of these features, considering how many users would likely buy (or not buy) the mobile player based on having the feature or not. If the potential value of the product sales is $10 million and you choose not to build the expected continuous play feature, your sales might drop to zero—therefore you can say that feature is a $10 million feature. Meanwhile, showing album covers on the music player might only be useful to a small subset of the users, so maybe it’s a $10,000 feature

Process Flows

After understanding the features, it’s equally important to think about how the user will experience the functionality step by step. “Process flows” can be created to show this, by thinking about what the user is trying to do (what the initial problem is they are solving) at each step and describing the flow in that manner. The flows should be based on how the user will receive value, not how they access specific functions in the product. If a user just bought the music player, the first step in the flow is to open the box. Then what? The flow should have a very short path to get their old music onto the new device. Keep in mind that different types of users might have different problems to be solved and different expectations, so there might be different process flows for different personas.

It is important to think about product usability, since we not only must implement features that add value for the users, we need to implement them in a way that meets users’ needs so they will adopt the products. You can use the process flows to improve the usability of the product. Consider how many steps a user has to go through to receive the desired value from a feature, and try to reduce those.

In our mobile music example, a user opening the box shouldn’t face a long setup process including settings they won’t use immediately, until finally (and frustratingly) they can at last play music—but they have none loaded. We want them to get to a basic set of functionality right out of the box and worry about other features later.

Requirements Mapping Matrix

The process flows can also be used to identify specific requirements and business rules that are needed to support the in-scope features. And by organizing your requirements by process flow steps in a “requirements mapping matrix” (RMM), you are able to later understand the impact of cutting a feature or changing the user’s flow to access it. An RMM provides “traceablity” and the ability to demonstrate completeness. It is like a traceability matrix, but allows more mappings at once—such as mapping user’s objective to process flow steps to requirements and business rules. Figure 2 shows an example of an RMM.

Figure 2. An Example Requirements Mapping Matrix

Using an RMM, you can also tie these models and the individual requirements back to the user’s original objectives. As you add requirements, you can verify they contribute to the user’s overall objectives. As you cut requirements, you can ensure that they are safe to cut and that the processes they support can still be executed.

Models to Identify the Minimum Viable Product

There are a few basic requirements models that can be applied easily and immediately to any product development effort. The intent is not to propose that you create a lot of useless requirements documentation. Instead, if you select the right models, you can ensure you cut scope and only work on requirements documentation for the needed features. All the while, you are creating a more successful product that will have only the features the user actually needs—and you will have delivered it for less.

]]>
tag:feedblitz.com,2012-10-22:36474/http://feeds.feedblitz.com/~/158958258/0/pragmaticmarketing/articles/requirements/3cefda9dd974ce3f7179c865b3177a54http://pragmaticmarketing.com/agility_articles/redirect?id=4171http://feeds.feedblitz.com/~/158958262/0/pragmaticmarketing/articles/requirements~We-All-Need-To-Be-NimbleWhen Agile first showed up on the development radar, we used to sort a room full of people by a show of hands: These people were Agile, and these people were not. It was that binary.

The hands still go up for using Agile today, but then they flavor it with “we practice Agile sometimes” or “we took some characteristics and adapted it to the organization.”

The need to quickly adapt to changes stayed the same, but people are approaching it differently.

A Desire to be Nimble

To understand the state of development today, we need to go back to Agile’s roots. Back then, the way we determined what to build and how we built it was very straightforward. We went out and interacted with the market, figured out what was broken in people’s lives and documented it. Then we turned around to development and said: “Here are the problems we’ve got, can you make these go away?”

But in some cases, by the time all that thinking, planning, sharing, building and testing was done, the problems had changed. Our industry just couldn’t respond quickly enough. So the Agile movement came out of development as a way to incorporate new information along the way.

The fundamentals didn’t change for product management or marketing. We still needed to get outside of the building, interact with all the different representatives of our market and key in on the problems we were going to solve. But how and when development wanted that information changed.

The development organization wanted artifacts that were smaller, bite-sized pieces. And they wanted to have ready access to someone who was plugged into the market, so that they could make adjustments throughout the development cycle as the market changed. Agile was born, and to many it appeared to be a whole different way of building products.

Creating a Nimble Business

Over the last decade, we’ve seen just about everybody use some form of these techniques to react to changes in the market, the competition and development. We all need to pivot when change comes about, not just Agile shops.

Sometimes, parts of the organization went Agile, but not all. A company once told me their development team worked in week-long increments iterations and could take what they built, test it and have it ready for shipment at the end of any given monthly cycle.

But when I asked them when they last shipped, their head of development told me it was 18 months prior.

The issue, he said, was “THEY keep changing things.” He was referring to the rest of the company, who would continually ask for more features, which the team built. But nobody ever asked them to bottle up the product and ship it. Clearly, this approach wasn’t working.

The company then decided to prioritize shipping a product in step with the cycles of their market. Sales, marketing, customer support and the customers were set up for delivery every six months. Meanwhile, development stayed on month-long cycles and could readily adapt to things they learned while developing, or if something new happened in the market—a change in market problems or competitive pressure.

Everyone was working together more effectively, and the organization had more success because it was more predictable—both internally and externally. And the developers were happier because they were seeing their products go out the door, instead of just sitting and languishing on the shelf. The organization now had a structure that helped incorporate the needs of the business and the needs of the customer without being methodology specific.

Working Across Methodologies

There was a point in time when Agile was new, and some companies were exclusively Agile. We had two requirements-oriented courses here at Pragmatic Marketing, because there was this impression that Agile shops were so different that they had to have something that was explicitly for them. That’s just not the case anymore.

What we’ve learned by talking to our market is that today everybody has gone to some sort of hybrid methodology, taking the best of Agile and non-Agile worlds and combining them. When we saw that was happening, we knew we wanted to do the same by incorporating the best of our Requirements That Work and Living in an Agile World courses to create a response to the hybrid environment in the market. We know that everyone wants to be nimble. And our new Build course addresses that and is going to be appropriate for you, no matter what methodology you’re practicing.

]]>
Mon, 22 Oct 2012 00:00:00 -0400When Agile first showed up on the development radar, we used to sort a room full of people by a show of hands: These people were Agile, and these people were not. It was that binary.

The hands still go up for using Agile today, but then they flavor it with “we practice Agile sometimes” or “we took some characteristics and adapted it to the organization.”

The need to quickly adapt to changes stayed the same, but people are approaching it differently.

A Desire to be Nimble

To understand the state of development today, we need to go back to Agile’s roots. Back then, the way we determined what to build and how we built it was very straightforward. We went out and interacted with the market, figured out what was broken in people’s lives and documented it. Then we turned around to development and said: “Here are the problems we’ve got, can you make these go away?”

But in some cases, by the time all that thinking, planning, sharing, building and testing was done, the problems had changed. Our industry just couldn’t respond quickly enough. So the Agile movement came out of development as a way to incorporate new information along the way.

The fundamentals didn’t change for product management or marketing. We still needed to get outside of the building, interact with all the different representatives of our market and key in on the problems we were going to solve. But how and when development wanted that information changed.

The development organization wanted artifacts that were smaller, bite-sized pieces. And they wanted to have ready access to someone who was plugged into the market, so that they could make adjustments throughout the development cycle as the market changed. Agile was born, and to many it appeared to be a whole different way of building products.

Creating a Nimble Business

Over the last decade, we’ve seen just about everybody use some form of these techniques to react to changes in the market, the competition and development. We all need to pivot when change comes about, not just Agile shops.

Sometimes, parts of the organization went Agile, but not all. A company once told me their development team worked in week-long increments iterations and could take what they built, test it and have it ready for shipment at the end of any given monthly cycle.

But when I asked them when they last shipped, their head of development told me it was 18 months prior.

The issue, he said, was “THEY keep changing things.” He was referring to the rest of the company, who would continually ask for more features, which the team built. But nobody ever asked them to bottle up the product and ship it. Clearly, this approach wasn’t working.

The company then decided to prioritize shipping a product in step with the cycles of their market. Sales, marketing, customer support and the customers were set up for delivery every six months. Meanwhile, development stayed on month-long cycles and could readily adapt to things they learned while developing, or if something new happened in the market—a change in market problems or competitive pressure.

Everyone was working together more effectively, and the organization had more success because it was more predictable—both internally and externally. And the developers were happier because they were seeing their products go out the door, instead of just sitting and languishing on the shelf. The organization now had a structure that helped incorporate the needs of the business and the needs of the customer without being methodology specific.

Working Across Methodologies

There was a point in time when Agile was new, and some companies were exclusively Agile. We had two requirements-oriented courses here at Pragmatic Marketing, because there was this impression that Agile shops were so different that they had to have something that was explicitly for them. That’s just not the case anymore.

What we’ve learned by talking to our market is that today everybody has gone to some sort of hybrid methodology, taking the best of Agile and non-Agile worlds and combining them. When we saw that was happening, we knew we wanted to do the same by incorporating the best of our Requirements That Work and Living in an Agile World courses to create a response to the hybrid environment in the market. We know that everyone wants to be nimble. And our new Build course addresses that and is going to be appropriate for you, no matter what methodology you’re practicing.

]]>
tag:feedblitz.com,2012-10-22:36474/http://feeds.feedblitz.com/~/158958262/0/pragmaticmarketing/articles/requirements/177108af09fd602ac8f369370ccbd9e1http://pragmaticmarketing.com/agility_articles/redirect?id=2958http://feeds.feedblitz.com/~/158958268/0/pragmaticmarketing/articles/requirements~Writing-the-Market-Requirements-DocumentWriting requirements is not a mysterious black art although it may sometimes seem that way. Requirements convey details of a customer's problem to the reader (usually a designer or developer). A requirement reveals the information necessary to create an innovative solution to the problem, perhaps in ways not anticipated by either the requirement's writer or the associated end-user. Understanding the market is the first step in creating innovative products. The collection of market requirements is the body of what’s often called a “Market Requirements Document.”

The Five Steps of Innovation

Successful organizations use five steps for developing innovative products:

Find a problem

Analyze it

Design an innovative solution

Code to the design

Test the result

Sadly, these steps are not always followed. Many product managers fail to communicate lucid requirements grounded in the market; too few developers analyze the problem and design an innovative solution. Yet successful technology organizations routinely and consistently follow all five steps.

Alan Cooper, in his book The Inmates are Running the Asylum, says most technical products aren’t designed for the user; they’re designed for the developer. Or worse, they’re not designed at all. Poorly designed products frustrate customers.

Whether using traditional methods or agile ones, we need to understand the problem before building a feature. You’ll need a design before you begin building. Agile methodologies aren’t just about coding; agile teams learn to move through the five steps of innovation quickly and efficiently, usually completing an entire development cycle in a few weeks.

In many organizations, the product management function is ill-defined. Ideally, a product manager finds problems in the marketplace and conveys them to a Development or Engineering organization. When product managers (sometimes called product owners) are also competent in development areas, they’re often recruited to assist in other areas of product development. Since many come from a technical background, they have a natural tendency to work on activities they enjoy and where they have skills, even though these activities are not product management responsibilities. As a result, product managers are often overwhelmed with tactical, technical activities that tie them to their desks; activities that prevent them from spending time in the market. For more on the role, see The Strategic Role of Product Management e-book.

A product manager owns the first step in creating innovative products: finding market problems. These are communicated to Development in the form of requirements—the problems to be solved. The remaining steps of innovation are owned by the Development or Engineering departments. A product architect or designer controls the middle steps (analysis and high-level design) with a team lead in charge of the detailed design, coding and testing. If there is no designer, then analysis and design falls to the Development team. Another critical role is QA. The quality assurance lead is responsible for both internal and external testing. That’s why QA should head up the alpha and beta testing projects. The QA lead validates that the specifications (written by Development) address the problems articulated in the requirements (written by product management) and then tests the result to ensure the requirement is met; this verification role is more effective than merely attempting to "break the code" in clever ways.

So the functions (and roles) are:

Find a problem (product manager)

Analyze it (product architect or designer)

Design a solution (product architect or designer)

Code (developer)

Test (QA lead)

Nowadays, we see personas and problems increasingly used as the primary method of defining complex projects, with an associated reduction in the old "reqs and specs" approach. An emphasis on personas and their problems focuses the team on the final result, rather than the tedious implementation of individual features. This approach requires more analysis and design by Development, making it more attractive to competent development organizations.

At Pragmatic Marketing, we have long been advocates of personas, both for the users of the product as well as for buyers. Buyers have one set of requirements; users have another. And for most technology products, the buyers and users are different people in the organization. A buyer persona is involved in the purchase of the product; a user persona actually uses the product. The buyer persona is concerned with value while a user persona is more concerned with capabilities. A persona defines an archetype of the buyer or user of your product with a biography that includes context to guide the team. For example, knowing a typical customer—a user persona—is adept at spreadsheets suggests we don’t need a report writer but can implement an export capability instead.

Personas have problems. Stated in the context of a specific persona, a problem represents a situation that our product should be able to address. Problems are specific situations that can be clearly expressed.

The persona definitions and the list of their problems are the basis of the Market Requirements Document (MRD). MRD articulates the new product or new release plan. Some companies call this document a Product Requirements Document (PRD). Some organizations have both an MRD and a PRD but then struggle to define which is which and what each should contain.

Let’s keep it simple:

A business plan defines the overall product opportunity with a financial plan; a requirements document defines the next version or model of a product with a list of problems to be solved.

Do we really need more documents than this?

Traditional Requirements

According to the IEEE definition, a requirement is a statement identifying a capability, physical characteristic, or quality factor that bounds a product or process problem for which a solution will be pursued.

Focus on the ending phrase: Requirements state a “problem for which a solution will be pursued.”

Traditional requirements are categorized into these five types:

Functional. Observable capabilities that must be present for the persona to complete their goals or perform the task specified by the use scenario

Performance. Characteristics of capacity, speed, concurrency

Constraints. Conditions that legitimately limit the design

Interface. Defined interaction with hardware and software components

Security. Compliance with government mandate and customer privacy

Software vendors may also need to consider these unofficial types of requirements (not recognized by IEEE). For example:

Standardization

Certification

Installation

Implementation

Customization

Localization

Documentation

Education

Alas, we often see this traditional approach implemented poorly, combining the requirement with a specification; a statement of the problem as well as a proposed solution to the problem. Clearly the IEEE standard requires these to stay separate.

However, these types of requirements remind us to look beyond problems that result in a feature (functional requirements) to include problems that impact performance, installation, customization, and so on (non-functional requirements). Whatever form you use, be sure to convey the parameters of the problem.

Today’s requirements are written in the words of the persona, in business or personal terms, rather than offering a technical definition. A requirement should be short, only one or two paragraphs, never more than a page or two.

The key: Product managers write requirements to document the problem without a recommended solution to the problem. The Market Requirements Document combines the many requirements into a coherent whole. For a new product, a requirement states a business problem the potential customer is having that will be addressed; for an existing product, the requirement might instead document a usage problem for existing customers.

Characteristics of a Good Requirement

A good requirement conveys the context of the problem. How do you know you’ve done it right?

There are a few ways to evaluate your requirement before you get it in front of a team of designers. One method is SMART, which stands for:

Specific. Requirements should specify what they are to achieve.

Measurable. The requirements should provide a metric whereby all stakeholders can determine if the objectives are being met.

Achievable. Are the requirements' objectives achievable and attainable?

Realistic. Are the requirements realistic with respect to the available resources?

Time-Bound. When is the team to achieve the requirements' objectives?

The trick of writing good requirements is to convey the critical information in a form that developers and designers can embrace -- enough detail to provide context without too much detail that overwhelms the reader. A well-written requirement helps the designer make judgment decisions without turning to the product manager continually throughout the day. Ask yourself: When an implementation question arises, have I provided adequate context? Can the designer imagine the appropriate solution? And for that matter, ask your team: “Have I communicated clearly?”

Requirements That Work

The story approach to writing requirements often works to everyone’s advantage. “Tell me a story. What is happening? What is the persona trying to achieve?”

There are many formats and definitions for stories. Some call them use cases; others call them user stories. Our preferred format is a use scenario, taught in our Build course:

[Persona] has [problem] with [frequency]

For example, Sarah the college student needs to pay her tuition each semester using multiple credit cards.

"Sarah" is the persona, "pay tuition" is the problem, and "each semester" reveals the frequency of the problem. And notice this problem is absent a proposed solution; that’s up to the people doing the design.

Stories are powerful. You put the designer in the customer’s chair, seeing the problem from the customer’s point of view. Use scenarios explain to the designer or developer why a solution to this problem is needed. The use scenario illustrates how the problem occurs; it puts the problem in context. The tone is "imagine if you will," so the person designing the solution can viscerally understand the problem.

You should provide contact information for two or three potential users of the product who can be reached by the designers when clarification is required. A product manager is usually not a necessary interface between the developer and the customer; include phone numbers and email addresses so the team can contact them directly.

What is the persona doing to cause this problem?

How does the persona do it now?

How might the persona like to do it?

When questions arise about an implementation choice, the team should find the answer in the use scenario. Also, provide requirements and use scenarios to QA for their test plans. The ideal test plan ensures that the problem was resolved, not that the design was achieved.

Artifacts for Requirements

Now that we have the detailed documents—the personas and their problems—what form should be used to communicate to the organization? These documents need to be more than a “cocktail napkin” but don’t need to be multi-hundred-page tomes. They are:

Business plan

Product roadmap

Requirements

A business plan includes information about the business of the product. Typically, we update the business plan annually to compare last year’s goals to the actual results. Items that belong in the business plan are:

Research regarding market problems

Results from win/loss analysis

Market definition and sizing

Distribution strategy

Distinctive competence

Financial plan

A product roadmap has become the most popular artifact for representing product strategy. A roadmap shows phases of deliverables over the next 18-36 months or through the next three or four product releases. Most teams prefer to keep the roadmap as a separate document to share with both executives and the product team but some firms include this document in the business plan. For more on product roadmaps, see Product Roadmapping.

The Requirements document--whether called a Market Requirements Document (MRD) or a Product Requirements Document (PRD) or a backlog or something else--contains a prioritized list of problems for your target personas. Contents include:

Persona definitions

Phases of deliverables

Requirements (problems with use scenarios and frequency)

There you have it. A business case reveals your plans for the product as a whole. The roadmap shows phases of deliverables over the next few cycles. The requirements document contains the details of the problems that will be addressed in the next release or product version.

Requirements explain the personas and their problems. Tell a story to help the team understand the persona’s frustration. By providing this context, the product team understands whether a feature should be implemented for power or ease-of-use; the team members will focus on delighting personas instead of themselves. And we’ll get a product that people will want to buy.

Attend Pragmatic Marketing's Build to learn techniques for prioritizing and organizing requirements to maximize the impact of releases.

]]>
Fri, 04 Nov 2011 00:00:00 -0400Writing requirements is not a mysterious black art although it may sometimes seem that way. Requirements convey details of a customer's problem to the reader (usually a designer or developer). A requirement reveals the information necessary to create an innovative solution to the problem, perhaps in ways not anticipated by either the requirement's writer or the associated end-user. Understanding the market is the first step in creating innovative products. The collection of market requirements is the body of what’s often called a “Market Requirements Document.”

The Five Steps of Innovation

Successful organizations use five steps for developing innovative products:

Find a problem

Analyze it

Design an innovative solution

Code to the design

Test the result

Sadly, these steps are not always followed. Many product managers fail to communicate lucid requirements grounded in the market; too few developers analyze the problem and design an innovative solution. Yet successful technology organizations routinely and consistently follow all five steps.

Alan Cooper, in his book The Inmates are Running the Asylum, says most technical products aren’t designed for the user; they’re designed for the developer. Or worse, they’re not designed at all. Poorly designed products frustrate customers.

Whether using traditional methods or agile ones, we need to understand the problem before building a feature. You’ll need a design before you begin building. Agile methodologies aren’t just about coding; agile teams learn to move through the five steps of innovation quickly and efficiently, usually completing an entire development cycle in a few weeks.

In many organizations, the product management function is ill-defined. Ideally, a product manager finds problems in the marketplace and conveys them to a Development or Engineering organization. When product managers (sometimes called product owners) are also competent in development areas, they’re often recruited to assist in other areas of product development. Since many come from a technical background, they have a natural tendency to work on activities they enjoy and where they have skills, even though these activities are not product management responsibilities. As a result, product managers are often overwhelmed with tactical, technical activities that tie them to their desks; activities that prevent them from spending time in the market. For more on the role, see The Strategic Role of Product Management e-book.

A product manager owns the first step in creating innovative products: finding market problems. These are communicated to Development in the form of requirements—the problems to be solved. The remaining steps of innovation are owned by the Development or Engineering departments. A product architect or designer controls the middle steps (analysis and high-level design) with a team lead in charge of the detailed design, coding and testing. If there is no designer, then analysis and design falls to the Development team. Another critical role is QA. The quality assurance lead is responsible for both internal and external testing. That’s why QA should head up the alpha and beta testing projects. The QA lead validates that the specifications (written by Development) address the problems articulated in the requirements (written by product management) and then tests the result to ensure the requirement is met; this verification role is more effective than merely attempting to "break the code" in clever ways.

So the functions (and roles) are:

Find a problem (product manager)

Analyze it (product architect or designer)

Design a solution (product architect or designer)

Code (developer)

Test (QA lead)

Nowadays, we see personas and problems increasingly used as the primary method of defining complex projects, with an associated reduction in the old "reqs and specs" approach. An emphasis on personas and their problems focuses the team on the final result, rather than the tedious implementation of individual features. This approach requires more analysis and design by Development, making it more attractive to competent development organizations.

At Pragmatic Marketing, we have long been advocates of personas, both for the users of the product as well as for buyers. Buyers have one set of requirements; users have another. And for most technology products, the buyers and users are different people in the organization. A buyer persona is involved in the purchase of the product; a user persona actually uses the product. The buyer persona is concerned with value while a user persona is more concerned with capabilities. A persona defines an archetype of the buyer or user of your product with a biography that includes context to guide the team. For example, knowing a typical customer—a user persona—is adept at spreadsheets suggests we don’t need a report writer but can implement an export capability instead.

Personas have problems. Stated in the context of a specific persona, a problem represents a situation that our product should be able to address. Problems are specific situations that can be clearly expressed.

The persona definitions and the list of their problems are the basis of the Market Requirements Document (MRD). MRD articulates the new product or new release plan. Some companies call this document a Product Requirements Document (PRD). Some organizations have both an MRD and a PRD but then struggle to define which is which and what each should contain.

Let’s keep it simple:

A business plan defines the overall product opportunity with a financial plan; a requirements document defines the next version or model of a product with a list of problems to be solved.

Do we really need more documents than this?

Traditional Requirements

According to the IEEE definition, a requirement is a statement identifying a capability, physical characteristic, or quality factor that bounds a product or process problem for which a solution will be pursued.

Focus on the ending phrase: Requirements state a “problem for which a solution will be pursued.”

Traditional requirements are categorized into these five types:

Functional. Observable capabilities that must be present for the persona to complete their goals or perform the task specified by the use scenario

Performance. Characteristics of capacity, speed, concurrency

Constraints. Conditions that legitimately limit the design

Interface. Defined interaction with hardware and software components

Security. Compliance with government mandate and customer privacy

Software vendors may also need to consider these unofficial types of requirements (not recognized by IEEE). For example:

Standardization

Certification

Installation

Implementation

Customization

Localization

Documentation

Education

Alas, we often see this traditional approach implemented poorly, combining the requirement with a specification; a statement of the problem as well as a proposed solution to the problem. Clearly the IEEE standard requires these to stay separate.

However, these types of requirements remind us to look beyond problems that result in a feature (functional requirements) to include problems that impact performance, installation, customization, and so on (non-functional requirements). Whatever form you use, be sure to convey the parameters of the problem.

Today’s requirements are written in the words of the persona, in business or personal terms, rather than offering a technical definition. A requirement should be short, only one or two paragraphs, never more than a page or two.

The key: Product managers write requirements to document the problem without a recommended solution to the problem. The Market Requirements Document combines the many requirements into a coherent whole. For a new product, a requirement states a business problem the potential customer is having that will be addressed; for an existing product, the requirement might instead document a usage problem for existing customers.

Characteristics of a Good Requirement

A good requirement conveys the context of the problem. How do you know you’ve done it right?

There are a few ways to evaluate your requirement before you get it in front of a team of designers. One method is SMART, which stands for:

Specific. Requirements should specify what they are to achieve.

Measurable. The requirements should provide a metric whereby all stakeholders can determine if the objectives are being met.

Achievable. Are the requirements' objectives achievable and attainable?

Realistic. Are the requirements realistic with respect to the available resources?

Time-Bound. When is the team to achieve the requirements' objectives?

The trick of writing good requirements is to convey the critical information in a form that developers and designers can embrace -- enough detail to provide context without too much detail that overwhelms the reader. A well-written requirement helps the designer make judgment decisions without turning to the product manager continually throughout the day. Ask yourself: When an implementation question arises, have I provided adequate context? Can the designer imagine the appropriate solution? And for that matter, ask your team: “Have I communicated clearly?”

Requirements That Work

The story approach to writing requirements often works to everyone’s advantage. “Tell me a story. What is happening? What is the persona trying to achieve?”

There are many formats and definitions for stories. Some call them use cases; others call them user stories. Our preferred format is a use scenario, taught in our Build course:

[Persona] has [problem] with [frequency]

For example, Sarah the college student needs to pay her tuition each semester using multiple credit cards.

"Sarah" is the persona, "pay tuition" is the problem, and "each semester" reveals the frequency of the problem. And notice this problem is absent a proposed solution; that’s up to the people doing the design.

Stories are powerful. You put the designer in the customer’s chair, seeing the problem from the customer’s point of view. Use scenarios explain to the designer or developer why a solution to this problem is needed. The use scenario illustrates how the problem occurs; it puts the problem in context. The tone is "imagine if you will," so the person designing the solution can viscerally understand the problem.

You should provide contact information for two or three potential users of the product who can be reached by the designers when clarification is required. A product manager is usually not a necessary interface between the developer and the customer; include phone numbers and email addresses so the team can contact them directly.

What is the persona doing to cause this problem?

How does the persona do it now?

How might the persona like to do it?

When questions arise about an implementation choice, the team should find the answer in the use scenario. Also, provide requirements and use scenarios to QA for their test plans. The ideal test plan ensures that the problem was resolved, not that the design was achieved.

Artifacts for Requirements

Now that we have the detailed documents—the personas and their problems—what form should be used to communicate to the organization? These documents need to be more than a “cocktail napkin” but don’t need to be multi-hundred-page tomes. They are:

Business plan

Product roadmap

Requirements

A business plan includes information about the business of the product. Typically, we update the business plan annually to compare last year’s goals to the actual results. Items that belong in the business plan are:

Research regarding market problems

Results from win/loss analysis

Market definition and sizing

Distribution strategy

Distinctive competence

Financial plan

A product roadmap has become the most popular artifact for representing product strategy. A roadmap shows phases of deliverables over the next 18-36 months or through the next three or four product releases. Most teams prefer to keep the roadmap as a separate document to share with both executives and the product team but some firms include this document in the business plan. For more on product roadmaps, see Product Roadmapping.

The Requirements document--whether called a Market Requirements Document (MRD) or a Product Requirements Document (PRD) or a backlog or something else--contains a prioritized list of problems for your target personas. Contents include:

Persona definitions

Phases of deliverables

Requirements (problems with use scenarios and frequency)

There you have it. A business case reveals your plans for the product as a whole. The roadmap shows phases of deliverables over the next few cycles. The requirements document contains the details of the problems that will be addressed in the next release or product version.

Requirements explain the personas and their problems. Tell a story to help the team understand the persona’s frustration. By providing this context, the product team understands whether a feature should be implemented for power or ease-of-use; the team members will focus on delighting personas instead of themselves. And we’ll get a product that people will want to buy.

Attend Pragmatic Marketing's Build to learn techniques for prioritizing and organizing requirements to maximize the impact of releases.

In today's issue I'm going to write about something that is near and dear to my heart, something that I have found tremendously helpful working with customers to implement new software and working on my own and with teammates to make important things happen. It's a way to understand the psychological stages which you – and everyone else I have ever met – go through when you work on a major new undertaking such as buying and implementing a software product. I call it the Four Phases of Implementation.

The Four Phases of Implementation is by no means my original idea. I first read about it in a book about proposal writing, I believe, and I believe the author did not claim the idea as his own. Rather, he was passing along an idea that was widespread. I, however, had never heard it before, and have found it extremely helpful ever since.

I have found the Four Phases of Implementation to be so useful, in fact, that at my current company I started paying a visit to each and every class of trainees in our product for the express purpose of describing the Four Phases. I know that by imparting this information to my customers, I can help them better work through the implementation of our software product. Not only does it help them directly, but I charge them with taking the Four Phases idea and walking their teammates through it when they get back at the office, all in the interest of making our product easier to adopt and making its implementation more successful.

ANY PROJECT CAN HAVE THESE FOUR PHASES

I think you'll find the Four Phases of Implementation to be a helpful concept that you can take with you from customer to customer, project to project, and job to job to help you remain focused on results when facing an undertaking that leaves you doubting your ability to get to the results you so badly want.

Through the four phases of an implementation, the morale of those participating in the project takes a predictable path. It is this morale that is necessary to the success of your project. The more morale can be increased, the more successful your implementation will be viewed. Understanding the four phases helps you manage and cultivate the high morale you are aiming for.

THE FIRST PHASE: OH BOY!

The first phase, the Oh Boy phase, is fun. "Oh Boy, we just purchased a new software product, and it's going to help us analyze our sales data and target new prospects a whole lot better!" This is the honeymoon phase.

Morale is very high in the Oh Boy phase. People are excited and optimistic, and probably have unrealistic expectations about the amount of time and effort that will be required to implement your software. They're looking forward to great improvements or even transformations from your product. The worst part about this phase is, like a honeymoon, how short it is.

THE SECOND PHASE: OH SHOOT!

I have often used a cruder version of the name for this phase, but I'll use this one in this article for politeness' sake. Feel free to use the version you prefer. This is the phase you'll wind up focusing on the most, since it's the toughest one.

When the reality sinks in about how much time and effort will be required to implement your software, people enter the Oh Shoot phase. Morale plummets during this phase. Instead of "Oh boy, this will help us fix our reports!" people are thinking: "Oh shoot, I can't believe how much work we must do to fix our data so that it will work right in the reports! How are we ever going to get that done? Will anyone even help us?"

When implementation projects hit the Oh Shoot phase and remain stuck there, that's when projects fail entirely. It is vital that you work to make the Oh Shoot phase as short as possible, and that you work to move everyone – yourself, your customers, every member of the team, every user – to the next phase.

By anticipating the Oh Shoot phase and planning to counter it, you will keep the implementation of your software on track.

THE THIRD PHASE: OH, WELL!

The third phase is the Oh, Well phase. "Oh, well, we have a lot of work to do to get our data where we need it to be, but once that's done, we'll have the reports that we have wanted for so long now." This phase can vary greatly in length, lasting from the end of the Oh Shoot phase all the way until your product is successfully implemented. The more time required to implement your product, the longer this phase will last.

In the Oh, Well phase, morale starts out low, right down where it dropped in the Oh Shoot phase. Then it slowly gets better as you make progress towards your implementation goals. As each unwelcome task is accomplished and each milestone is met, morale rises. The steadier your progress, the more steadily it rises.

It's critical to understand that morale in the Oh, Well phase doesn't start out very high, and doesn't rise very fast at first. That makes it hard to determine whether you are out of the Oh Shoot phase or not. Your implementation is making significant, even vital, progress when you have moved into the Oh, Well phase, but when you measure morale, it doesn't seem all that much better at first, so it can be hard to tell that the implementation is in fact progressing. Over time, it becomes clear that things are improving. The trick is to determine whether morale is improving, albeit slowly, in which case you are in the Oh, Well phase, or whether it is stagnant and you're stuck in the Oh Shoot phase.

The Oh Shoot phase doesn't end, and the Oh, Well phase doesn't start, until you resign yourself to the fact that implementation is going to be more difficult than you thought. You must face the fact that you are required to complete whatever work is necessary to get the software implemented the way you want.

To make your implementation succeed, it is essential that you help move yourself from the Oh Shoot to the Oh, Well phase. Face facts and resign yourself to the effort required. Then work to move your teammates, users, and managers to the Oh, Well phase also, so that your effort can make progress. As the Oh, Well phase progresses, morale starts to improve significantly, until you reach the final phase.

THE FOURTH PHASE: OH WOW!

The fourth and final phase is the Oh Wow phase: "Oh wow! Did you see these great reports? How did we ever do it without this software?" In this phase, morale climbs up high and stays there, as you realize the benefits of the software you have implemented.

It helps, during the sometimes very long Oh, Well phase, to remind yourself and your teammates that the Oh Wow phase will indeed happen, and that things will look much brighter then. With a successful implementation, the benefits and improvements are clear, and it's worth getting excited and celebrating. You can look back with the team at the Oh Boy phase, laugh about the Oh Shoot phase, and pride yourself on making it through the Oh, Well phase.

THE MORALE ROLLER COASTER RIDE

As you move through the four phases, morale seems to drop and rise like a roller coaster. Even though morale plummets for the Oh Shoot phase, it helps to understand that this is normal and to be expected. Nothing's wrong with you, with your team, or with the product you have chosen. It's just that the pesky reality of limited time and resources has a way of worming its way into your grand dreams and ambitious plans. The more you can help your team realize that their drop in morale is normal and healthy, the sooner you can move your project to the Oh, Well phase.

MANY PEOPLE, MANY PASSAGES

Overall, you can chart a single line of progress for your implementation project as it moves through the four phases. But each individual on the project also moves through these four phases, potentially independently of their teammates and the overall project. Be sure to enlist the help of those team members who are the first to move from the Oh Shoot to the Oh, Well phase, so that they can help teammates who are still stuck. When a new team member comes on board, they will go from the Oh Boy phase to the Oh Shoot phase, and it's important to have teammates on the lookout and prepared to help the new member along.

WHEN THERE IS NO OH BOY PHASE

For certain individuals, there is no Oh Boy phase at the beginning. That happens when a project which is somebody else's Oh Boy idea gets dropped onto a subordinate's plate to complete. The person who receives the assignment, who may not have participated in the decision to implement the software and has no particular enthusiasm for it to begin with, goes straight to the Oh Shoot phase. These people are the ones who take the most work to get to the Oh, Well phase. And it is vital that you move them to the Oh, Well phase, or you may never see your customer get to Oh Wow.

LOTS OF PROJECTS HAVE THESE FOUR PHASES

When you think about it, you realize that the Four Phases applies not just to software implementation, but to lots of different kinds of projects and efforts. I can think of many past efforts of my own where the Four Phases applied.

For example, when you decide to host a customer conference: "Oh boy, we're going to have a customer conference and it's going to be great for our product's reputation in the market. Oh, shoot, I can't believe how much work we're going to have to do to prepare! We have to choose a facility, and it's expensive! We have to get the sales force involved, and convince customers to come! Oh, well, it's going to mean lots of negotiations with the hotel and lots of calls to customers, but I think we'll get there. Oh, well, we didn't get as many rooms as we wanted, but we got a good rate for the early registrations. Oh, well, one of the top customers whom I wanted to present can't make it, but it looks like we'll have decent attendance. Oh wow, look at how many people are here and how much they're all talking to each other! Why didn't we do this before?"

Another example is when you release a major new version of your product: "Oh boy, this is going to blow away the market! I can't believe all the new features we're going to have. Oh shoot, nobody understands the new features except for the developers, and nobody understands their explanations. Oh, well, we're going to have to sit down and deliver some knowledge transfer sessions. It's going to take some time before the Training department gets it and builds training materials that make it easier for everyone to learn it. Oh wow, people really like this new module!"

It's not just a customer who goes through the Four Phases during their implementation. As the software maker, you go through them, too. "Oh boy, we just signed a really big contract with a top name brand! Oh shoot, the person who's in charge of implementing our product didn't want the assignment! Oh, well, we have to do a lot of coaxing, but they're making progress. Oh wow, look at the things they're doing with it now! Oh boy, I think I'll ask them to be reference!" And so the story continues.

JOURNEY TO SUCCESS

By having a clear idea of the path your customers will inevitably take as they move through the implementation of your product, you help them avoid the pitfalls that derail so many well intended efforts, and build a base of successful stories out in the marketplace that help sell your product.

In today's issue I'm going to write about something that is near and dear to my heart, something that I have found tremendously helpful working with customers to implement new software and working on my own and with teammates to make important things happen. It's a way to understand the psychological stages which you – and everyone else I have ever met – go through when you work on a major new undertaking such as buying and implementing a software product. I call it the Four Phases of Implementation.

The Four Phases of Implementation is by no means my original idea. I first read about it in a book about proposal writing, I believe, and I believe the author did not claim the idea as his own. Rather, he was passing along an idea that was widespread. I, however, had never heard it before, and have found it extremely helpful ever since.

I have found the Four Phases of Implementation to be so useful, in fact, that at my current company I started paying a visit to each and every class of trainees in our product for the express purpose of describing the Four Phases. I know that by imparting this information to my customers, I can help them better work through the implementation of our software product. Not only does it help them directly, but I charge them with taking the Four Phases idea and walking their teammates through it when they get back at the office, all in the interest of making our product easier to adopt and making its implementation more successful.

ANY PROJECT CAN HAVE THESE FOUR PHASES

I think you'll find the Four Phases of Implementation to be a helpful concept that you can take with you from customer to customer, project to project, and job to job to help you remain focused on results when facing an undertaking that leaves you doubting your ability to get to the results you so badly want.

Through the four phases of an implementation, the morale of those participating in the project takes a predictable path. It is this morale that is necessary to the success of your project. The more morale can be increased, the more successful your implementation will be viewed. Understanding the four phases helps you manage and cultivate the high morale you are aiming for.

THE FIRST PHASE: OH BOY!

The first phase, the Oh Boy phase, is fun. "Oh Boy, we just purchased a new software product, and it's going to help us analyze our sales data and target new prospects a whole lot better!" This is the honeymoon phase.

Morale is very high in the Oh Boy phase. People are excited and optimistic, and probably have unrealistic expectations about the amount of time and effort that will be required to implement your software. They're looking forward to great improvements or even transformations from your product. The worst part about this phase is, like a honeymoon, how short it is.

THE SECOND PHASE: OH SHOOT!

I have often used a cruder version of the name for this phase, but I'll use this one in this article for politeness' sake. Feel free to use the version you prefer. This is the phase you'll wind up focusing on the most, since it's the toughest one.

When the reality sinks in about how much time and effort will be required to implement your software, people enter the Oh Shoot phase. Morale plummets during this phase. Instead of "Oh boy, this will help us fix our reports!" people are thinking: "Oh shoot, I can't believe how much work we must do to fix our data so that it will work right in the reports! How are we ever going to get that done? Will anyone even help us?"

When implementation projects hit the Oh Shoot phase and remain stuck there, that's when projects fail entirely. It is vital that you work to make the Oh Shoot phase as short as possible, and that you work to move everyone – yourself, your customers, every member of the team, every user – to the next phase.

By anticipating the Oh Shoot phase and planning to counter it, you will keep the implementation of your software on track.

THE THIRD PHASE: OH, WELL!

The third phase is the Oh, Well phase. "Oh, well, we have a lot of work to do to get our data where we need it to be, but once that's done, we'll have the reports that we have wanted for so long now." This phase can vary greatly in length, lasting from the end of the Oh Shoot phase all the way until your product is successfully implemented. The more time required to implement your product, the longer this phase will last.

In the Oh, Well phase, morale starts out low, right down where it dropped in the Oh Shoot phase. Then it slowly gets better as you make progress towards your implementation goals. As each unwelcome task is accomplished and each milestone is met, morale rises. The steadier your progress, the more steadily it rises.

It's critical to understand that morale in the Oh, Well phase doesn't start out very high, and doesn't rise very fast at first. That makes it hard to determine whether you are out of the Oh Shoot phase or not. Your implementation is making significant, even vital, progress when you have moved into the Oh, Well phase, but when you measure morale, it doesn't seem all that much better at first, so it can be hard to tell that the implementation is in fact progressing. Over time, it becomes clear that things are improving. The trick is to determine whether morale is improving, albeit slowly, in which case you are in the Oh, Well phase, or whether it is stagnant and you're stuck in the Oh Shoot phase.

The Oh Shoot phase doesn't end, and the Oh, Well phase doesn't start, until you resign yourself to the fact that implementation is going to be more difficult than you thought. You must face the fact that you are required to complete whatever work is necessary to get the software implemented the way you want.

To make your implementation succeed, it is essential that you help move yourself from the Oh Shoot to the Oh, Well phase. Face facts and resign yourself to the effort required. Then work to move your teammates, users, and managers to the Oh, Well phase also, so that your effort can make progress. As the Oh, Well phase progresses, morale starts to improve significantly, until you reach the final phase.

THE FOURTH PHASE: OH WOW!

The fourth and final phase is the Oh Wow phase: "Oh wow! Did you see these great reports? How did we ever do it without this software?" In this phase, morale climbs up high and stays there, as you realize the benefits of the software you have implemented.

It helps, during the sometimes very long Oh, Well phase, to remind yourself and your teammates that the Oh Wow phase will indeed happen, and that things will look much brighter then. With a successful implementation, the benefits and improvements are clear, and it's worth getting excited and celebrating. You can look back with the team at the Oh Boy phase, laugh about the Oh Shoot phase, and pride yourself on making it through the Oh, Well phase.

THE MORALE ROLLER COASTER RIDE

As you move through the four phases, morale seems to drop and rise like a roller coaster. Even though morale plummets for the Oh Shoot phase, it helps to understand that this is normal and to be expected. Nothing's wrong with you, with your team, or with the product you have chosen. It's just that the pesky reality of limited time and resources has a way of worming its way into your grand dreams and ambitious plans. The more you can help your team realize that their drop in morale is normal and healthy, the sooner you can move your project to the Oh, Well phase.

MANY PEOPLE, MANY PASSAGES

Overall, you can chart a single line of progress for your implementation project as it moves through the four phases. But each individual on the project also moves through these four phases, potentially independently of their teammates and the overall project. Be sure to enlist the help of those team members who are the first to move from the Oh Shoot to the Oh, Well phase, so that they can help teammates who are still stuck. When a new team member comes on board, they will go from the Oh Boy phase to the Oh Shoot phase, and it's important to have teammates on the lookout and prepared to help the new member along.

WHEN THERE IS NO OH BOY PHASE

For certain individuals, there is no Oh Boy phase at the beginning. That happens when a project which is somebody else's Oh Boy idea gets dropped onto a subordinate's plate to complete. The person who receives the assignment, who may not have participated in the decision to implement the software and has no particular enthusiasm for it to begin with, goes straight to the Oh Shoot phase. These people are the ones who take the most work to get to the Oh, Well phase. And it is vital that you move them to the Oh, Well phase, or you may never see your customer get to Oh Wow.

LOTS OF PROJECTS HAVE THESE FOUR PHASES

When you think about it, you realize that the Four Phases applies not just to software implementation, but to lots of different kinds of projects and efforts. I can think of many past efforts of my own where the Four Phases applied.

For example, when you decide to host a customer conference: "Oh boy, we're going to have a customer conference and it's going to be great for our product's reputation in the market. Oh, shoot, I can't believe how much work we're going to have to do to prepare! We have to choose a facility, and it's expensive! We have to get the sales force involved, and convince customers to come! Oh, well, it's going to mean lots of negotiations with the hotel and lots of calls to customers, but I think we'll get there. Oh, well, we didn't get as many rooms as we wanted, but we got a good rate for the early registrations. Oh, well, one of the top customers whom I wanted to present can't make it, but it looks like we'll have decent attendance. Oh wow, look at how many people are here and how much they're all talking to each other! Why didn't we do this before?"

Another example is when you release a major new version of your product: "Oh boy, this is going to blow away the market! I can't believe all the new features we're going to have. Oh shoot, nobody understands the new features except for the developers, and nobody understands their explanations. Oh, well, we're going to have to sit down and deliver some knowledge transfer sessions. It's going to take some time before the Training department gets it and builds training materials that make it easier for everyone to learn it. Oh wow, people really like this new module!"

It's not just a customer who goes through the Four Phases during their implementation. As the software maker, you go through them, too. "Oh boy, we just signed a really big contract with a top name brand! Oh shoot, the person who's in charge of implementing our product didn't want the assignment! Oh, well, we have to do a lot of coaxing, but they're making progress. Oh wow, look at the things they're doing with it now! Oh boy, I think I'll ask them to be reference!" And so the story continues.

JOURNEY TO SUCCESS

By having a clear idea of the path your customers will inevitably take as they move through the implementation of your product, you help them avoid the pitfalls that derail so many well intended efforts, and build a base of successful stories out in the marketplace that help sell your product.

Product management is all about trade-offs. Whether the objective is increased market share, profit margin or revenue, every product manager makes trade-offs—quality vs. cost, time to market vs. breadth of features, richness of the offering vs. ease of use, etc.

So, how do you know what the market wants? What market segments exist? What those segments prefer? What will they pay? In short, how do you know what trade-offs to make? The answer is to get the market to make the trade-offs for you. Not the entire market, of course, just a representative sample of the market.

By using conjoint analysis, you, as a product manager, can do just that: understand the trade-offs you should make by understanding the trade-offs your market will make. Then, apply your increased market insight to your revenue, profit or share objective.

Is conjoint analysis right for me?

Conjoint analysis has been successfully applied in many industries, such as Air Travel, Smart Phones, Computers, Financial Services, Health Care, Real Estate, and Electronics. If your job includes configuring a defined set of features for a product or service and the consumer’s purchase decision will be “rational,” conjoint analysis can help. If, on the other hand, your consumer’s purchase decision will be “impulse” or “image,” conjoint is not the right tool for you. If you’re a technology product manager, conjoint analysis is right up your alley.

Because conjoint analysis helps you understand your market’s preferences, you can apply it to a variety of difficult aspects of the job, including product development, competitive positioning, pricing, product line analysis, segmentation and resource allocation. “How should we price our new product to maximize adoption?” “What features should we include in our next release to take market share from our competition?” “If we expand our product line, will overall revenue grow, or will we suffer too much cannibalization?” “For which value-added features is the market willing to pay?”

For example, a technology company was feeling pressure from a lower cost alternative and debated lowering its own prices. Then, the results of a conjoint analysis showed the market valued their products differently from the competitors. They chose not to lower prices, but to slightly reconfigure their offering. As a result, the business grew and realized substantial profits that they otherwise would have never seen. Not every situation is as dramatic as that, of course, but a conjoint analysis done right is impactful.

Conjoint analysis is a set of market research techniques that measures the value the market
places on each feature of your product and predicts the value of any combination of features.
Conjoint analysis is, at its essence, all about features and trade-offs.

What exactly is conjoint analysis?

Conjoint analysis is a set of market research techniques that measures the value the market places on each feature of your product and predicts the value of any combination of features. Conjoint analysis is, at its essence, all about features and trade-offs. With conjoint analysis, you:

Ask questions that force respondents to make trade-offs among features

Determine the value they place on each feature based on the trade-offs they make

Simulate how the market reacts to various feature trade-offs you are considering

To demonstrate conjoint analysis in action, let’s consider cell phone plans. These plans have various feature types, which in the language of conjoint analysis are called attributes. Let’s focus on Brand, Price, Minutes, Rollover Options, and Call Options. In reality, plans can be more complicated and conjoint analysis can keep up with the complexities, but let’s keep the example simple. Each of the attributes listed above has different levels. The levels of the Brand attribute might be AT&T, T-Mobile, Verizon, etc., but here we will refer to possible Brands as Brand A, Brand B, etc.

No free calling based on contacts
Free calling to top 5 contacts
Free calling to top 10 contacts

Attributes must be something you can categorize, but they don’t have to be numeric. Note that the attributes include brand, price, and various product features. Through conjoint analysis, you gain insights into the value of your brand and the value of product features, and determine price sensitivity.

Survey the market

Conjoint analysis survey questions could take a variety of forms, depending on your study objective, but the most common type of question would be:
Which of the following cell phone plans do you prefer?

Brand A

Brand B

Brand C

1,400 minutes

1,000 minutes

800 minutes

Unused minutes rollover for 1 month

No rollover of unused minutes

Unused minutes rollover for 1 year

No free calling based on contacts

Free calling to top 5 contacts

Free calling to top 10 contacts

Costs $100/month

Costs $75/month

Costs $60/month

Derive values for each of the levels

From responses to these questions, conjoint analysis uncovers the underlying value for each level, depending on how often a level was included in the product selected. The relative value of the levels is what is relevant, in other words, how the value of one level compares to the value of another.

For example, the values for the levels of the Call Options attribute and the Rollover
Options attribute for one respondent might be:

Call Options

Value

Rollover Options

Value

Free calling to top 10 contacts

50

Unused minutes rollover for 1 year

100

Free calling to top 5 contacts

20

Unused minutes rollover for 1 month

30

No free calling based on contacts

0

No rollover of unused minutes

0

You can see in this example, given the levels tested (which is an important caveat), the Rollover Options attribute (with values ranging from 0 to 100) was more important to the respondent than the Call Options attribute (with values ranging from 0 to 50). These values can be calculated for individuals as well as for the overall market, which means you can use conjoint analysis to segment your market based on respondent characteristics, needs and preferences. Each of the level values is called a part-worth, because they represent the worth of any given part of the product.

Predict preference for various products

Once you see the part-worths, you understand what trade-offs to make so a product will be more desirable to the market. This predictive capability is where the real power of conjoint analysis is evident. For example, given a set of part-worths, you might have the following scenario:

Brand A

30

Brand C

0

$75/month

40

$60/month

70

1,000 minutes

55

1,000 minutes

55

Unused minutes rollover for 1 month

30

No rollover of unused minutes

0

Free calling to top 5 contacts

20

Free calling to top 5 contacts

20

Total

175

Total

145

The total value of the Brand A product is 30 more than the Brand C product. This consumer would be more likely to select the Brand A product. But, if the Brand C call option was changed from “Free calling to top 5 contacts” (part-worth of 20) to “Free calling to top 10 contacts” (part-worth of 50), the overall value of each product would be the same and the consumer would be equally likely to select either product. The overall value of a product is referred to as its total utility.

Simulate competitive markets

Now that each attribute level has an associated part-worth, we can create any number of competitive scenarios by mixing and matching the levels and increasing or decreasing the number of products. The result of any conjoint analysis study is a simulation model that allows you to simulate, for example, what share of the market will prefer your product versus your competitors’ products. For example, you might see results like this:

Brand A

Brand B

Brand C

$60/month

$75/month

$75/month

1,000 minutes

1,400 minutes

1,000 minutes

Unused minutes rollover for 1 year

Unused minutes rollover for 1 month

Unused minutes rollover for 1 year

Free calling to top 5 contacts

Free calling to top 10 contacts

No free calling based on contacts

40% share

35% share

25% share

These shares, totaling 100%, are called “shares of preference,” because they refer to the share of the market that prefers each product, if everything else were equal. They are not market shares, because they don’t take into account a variety of other factors, such as sales and marketing efforts, distribution channels, product lifecycle phase, etc.

Simulating shares of preference is powerful. And, there’s no limit to the simulations you can run. So, for example, if your competitor changes its product, you can run simulations to help determine your response. If you are contemplating adding a new product, you can predict whether that will be beneficial and from which product in the existing market your new product will grab the most share. These are simple but potent examples of the many different ways that conjoint analysis may be used.
To get a complete picture of the competitive landscape, include all competitors, and to ensure the predictive capability of the approach over time, think carefully at the start about the attributes and levels you will include in the study.

That said, because it allows endless scenarios to be tested in a competitive landscape, share of preference allows for powerful “what if” analysis. It ultimately provides the insights you need to make the trade-offs you are faced with every day as a product manager. The insights gained regarding how you might change your position in the market, respond to competitive threats, grow revenue, penetrate specific segments, etc. can have a dramatic impact on the success of your product.

Analyze purchase likelihood

Even if your product is so new it has no competition and will create its own market, conjoint analysis provides powerful insights. In addition to market simulations and shares of preference, conjoint analysis also analyzes your product’s purchase likelihood. Purchase likelihood analysis uses the total utility of a product to determine a percentage indicating the relative likelihood that the product will be purchased, given various combinations of features and pricing.

Because purchase likelihood is single product focused and does not take into account the competition, it is particularly helpful when launching a product that is completely new to the marketplace. Purchase likelihood is often appropriate for micro-level product design as well, when major product decisions are already made, and the focus is on getting the details right.

What’s the best way to move forward?

There is software to help you design, conduct and analyze a conjoint analysis study yourself. But there are also nuances and important decisions to make in each step of the process. For example, there are different conjoint methodologies, each with its own approach to data collection. The one that is appropriate for you depends on the objectives of your study. Unless you’re going to personally do a conjoint study at least a few times a year, it’s likely that you will want to engage someone with experience in the field to help you navigate these nuances. Although surprising to many, the person you engage for your study need not be an expert in your field. You are that. They need only be expert in applying conjoint analysis to real business issues.

Just remember, the next time you’re making trade-offs as a product manager, use conjoint analysis to get your market to make the trade-offs for you.

]]>
Tue, 10 Aug 2010 00:00:00 -0400

Product management is all about trade-offs. Whether the objective is increased market share, profit margin or revenue, every product manager makes trade-offs—quality vs. cost, time to market vs. breadth of features, richness of the offering vs. ease of use, etc.

So, how do you know what the market wants? What market segments exist? What those segments prefer? What will they pay? In short, how do you know what trade-offs to make? The answer is to get the market to make the trade-offs for you. Not the entire market, of course, just a representative sample of the market.

By using conjoint analysis, you, as a product manager, can do just that: understand the trade-offs you should make by understanding the trade-offs your market will make. Then, apply your increased market insight to your revenue, profit or share objective.

Is conjoint analysis right for me?

Conjoint analysis has been successfully applied in many industries, such as Air Travel, Smart Phones, Computers, Financial Services, Health Care, Real Estate, and Electronics. If your job includes configuring a defined set of features for a product or service and the consumer’s purchase decision will be “rational,” conjoint analysis can help. If, on the other hand, your consumer’s purchase decision will be “impulse” or “image,” conjoint is not the right tool for you. If you’re a technology product manager, conjoint analysis is right up your alley.

Because conjoint analysis helps you understand your market’s preferences, you can apply it to a variety of difficult aspects of the job, including product development, competitive positioning, pricing, product line analysis, segmentation and resource allocation. “How should we price our new product to maximize adoption?” “What features should we include in our next release to take market share from our competition?” “If we expand our product line, will overall revenue grow, or will we suffer too much cannibalization?” “For which value-added features is the market willing to pay?”

For example, a technology company was feeling pressure from a lower cost alternative and debated lowering its own prices. Then, the results of a conjoint analysis showed the market valued their products differently from the competitors. They chose not to lower prices, but to slightly reconfigure their offering. As a result, the business grew and realized substantial profits that they otherwise would have never seen. Not every situation is as dramatic as that, of course, but a conjoint analysis done right is impactful.

Conjoint analysis is a set of market research techniques that measures the value the market
places on each feature of your product and predicts the value of any combination of features.
Conjoint analysis is, at its essence, all about features and trade-offs.

What exactly is conjoint analysis?

Conjoint analysis is a set of market research techniques that measures the value the market places on each feature of your product and predicts the value of any combination of features. Conjoint analysis is, at its essence, all about features and trade-offs. With conjoint analysis, you:

Ask questions that force respondents to make trade-offs among features

Determine the value they place on each feature based on the trade-offs they make

Simulate how the market reacts to various feature trade-offs you are considering

To demonstrate conjoint analysis in action, let’s consider cell phone plans. These plans have various feature types, which in the language of conjoint analysis are called attributes. Let’s focus on Brand, Price, Minutes, Rollover Options, and Call Options. In reality, plans can be more complicated and conjoint analysis can keep up with the complexities, but let’s keep the example simple. Each of the attributes listed above has different levels. The levels of the Brand attribute might be AT&T, T-Mobile, Verizon, etc., but here we will refer to possible Brands as Brand A, Brand B, etc.

No free calling based on contacts
Free calling to top 5 contacts
Free calling to top 10 contacts

Attributes must be something you can categorize, but they don’t have to be numeric. Note that the attributes include brand, price, and various product features. Through conjoint analysis, you gain insights into the value of your brand and the value of product features, and determine price sensitivity.

Survey the market

Conjoint analysis survey questions could take a variety of forms, depending on your study objective, but the most common type of question would be:
Which of the following cell phone plans do you prefer?

Brand A

Brand B

Brand C

1,400 minutes

1,000 minutes

800 minutes

Unused minutes rollover for 1 month

No rollover of unused minutes

Unused minutes rollover for 1 year

No free calling based on contacts

Free calling to top 5 contacts

Free calling to top 10 contacts

Costs $100/month

Costs $75/month

Costs $60/month

Derive values for each of the levels

From responses to these questions, conjoint analysis uncovers the underlying value for each level, depending on how often a level was included in the product selected. The relative value of the levels is what is relevant, in other words, how the value of one level compares to the value of another.

For example, the values for the levels of the Call Options attribute and the Rollover
Options attribute for one respondent might be:

Call Options

Value

Rollover Options

Value

Free calling to top 10 contacts

50

Unused minutes rollover for 1 year

100

Free calling to top 5 contacts

20

Unused minutes rollover for 1 month

30

No free calling based on contacts

0

No rollover of unused minutes

0

You can see in this example, given the levels tested (which is an important caveat), the Rollover Options attribute (with values ranging from 0 to 100) was more important to the respondent than the Call Options attribute (with values ranging from 0 to 50). These values can be calculated for individuals as well as for the overall market, which means you can use conjoint analysis to segment your market based on respondent characteristics, needs and preferences. Each of the level values is called a part-worth, because they represent the worth of any given part of the product.

Predict preference for various products

Once you see the part-worths, you understand what trade-offs to make so a product will be more desirable to the market. This predictive capability is where the real power of conjoint analysis is evident. For example, given a set of part-worths, you might have the following scenario:

Brand A

30

Brand C

0

$75/month

40

$60/month

70

1,000 minutes

55

1,000 minutes

55

Unused minutes rollover for 1 month

30

No rollover of unused minutes

0

Free calling to top 5 contacts

20

Free calling to top 5 contacts

20

Total

175

Total

145

The total value of the Brand A product is 30 more than the Brand C product. This consumer would be more likely to select the Brand A product. But, if the Brand C call option was changed from “Free calling to top 5 contacts” (part-worth of 20) to “Free calling to top 10 contacts” (part-worth of 50), the overall value of each product would be the same and the consumer would be equally likely to select either product. The overall value of a product is referred to as its total utility.

Simulate competitive markets

Now that each attribute level has an associated part-worth, we can create any number of competitive scenarios by mixing and matching the levels and increasing or decreasing the number of products. The result of any conjoint analysis study is a simulation model that allows you to simulate, for example, what share of the market will prefer your product versus your competitors’ products. For example, you might see results like this:

Brand A

Brand B

Brand C

$60/month

$75/month

$75/month

1,000 minutes

1,400 minutes

1,000 minutes

Unused minutes rollover for 1 year

Unused minutes rollover for 1 month

Unused minutes rollover for 1 year

Free calling to top 5 contacts

Free calling to top 10 contacts

No free calling based on contacts

40% share

35% share

25% share

These shares, totaling 100%, are called “shares of preference,” because they refer to the share of the market that prefers each product, if everything else were equal. They are not market shares, because they don’t take into account a variety of other factors, such as sales and marketing efforts, distribution channels, product lifecycle phase, etc.

Simulating shares of preference is powerful. And, there’s no limit to the simulations you can run. So, for example, if your competitor changes its product, you can run simulations to help determine your response. If you are contemplating adding a new product, you can predict whether that will be beneficial and from which product in the existing market your new product will grab the most share. These are simple but potent examples of the many different ways that conjoint analysis may be used.
To get a complete picture of the competitive landscape, include all competitors, and to ensure the predictive capability of the approach over time, think carefully at the start about the attributes and levels you will include in the study.

That said, because it allows endless scenarios to be tested in a competitive landscape, share of preference allows for powerful “what if” analysis. It ultimately provides the insights you need to make the trade-offs you are faced with every day as a product manager. The insights gained regarding how you might change your position in the market, respond to competitive threats, grow revenue, penetrate specific segments, etc. can have a dramatic impact on the success of your product.

Analyze purchase likelihood

Even if your product is so new it has no competition and will create its own market, conjoint analysis provides powerful insights. In addition to market simulations and shares of preference, conjoint analysis also analyzes your product’s purchase likelihood. Purchase likelihood analysis uses the total utility of a product to determine a percentage indicating the relative likelihood that the product will be purchased, given various combinations of features and pricing.

Because purchase likelihood is single product focused and does not take into account the competition, it is particularly helpful when launching a product that is completely new to the marketplace. Purchase likelihood is often appropriate for micro-level product design as well, when major product decisions are already made, and the focus is on getting the details right.

What’s the best way to move forward?

There is software to help you design, conduct and analyze a conjoint analysis study yourself. But there are also nuances and important decisions to make in each step of the process. For example, there are different conjoint methodologies, each with its own approach to data collection. The one that is appropriate for you depends on the objectives of your study. Unless you’re going to personally do a conjoint study at least a few times a year, it’s likely that you will want to engage someone with experience in the field to help you navigate these nuances. Although surprising to many, the person you engage for your study need not be an expert in your field. You are that. They need only be expert in applying conjoint analysis to real business issues.

Just remember, the next time you’re making trade-offs as a product manager, use conjoint analysis to get your market to make the trade-offs for you.