Guest Post – MindTheProducthttp://www.mindtheproduct.com
Product Management - the intersection of Business, Technology and the UserFri, 09 Dec 2016 14:10:15 +0000en-UShourly1https://wordpress.org/?v=4.6.1How to turn a story point factory into a customer-centric team?http://www.mindtheproduct.com/2016/11/how-to-turn-a-story-point-factory-into-a-customer-centric-team/
http://www.mindtheproduct.com/2016/11/how-to-turn-a-story-point-factory-into-a-customer-centric-team/#commentsTue, 22 Nov 2016 14:14:00 +0000http://www.mindtheproduct.com/?p=9662The one spontaneous ovation at this year’s London MTPCon was when Drift CEO David Cancel muttered “I hate agile” as an aside while he was on stage. Agile, a revolutionary idea 10 years ago, has clearly lost its shine for many people. However, almost all the product teams I know use some agile methods, and they […]

The one spontaneous ovation at this year’s London MTPCon was when Drift CEO David Cancel muttered “I hate agile” as an aside while he was on stage. Agile, a revolutionary idea 10 years ago, has clearly lost its shine for many people.

However, almost all the product teams I know use some agile methods, and they are certainly great tools to break down mega projects into manageable parts, to bring back flexibility to the development process or make it easier to estimate resources. But many people feel they have become story point implementing machines, and the focus on agile has meant that the original goals of focusing on clients and end users have become lost along the way. For them agile looks like a needless abstraction layer between the development team and their customers. How can we bring customers back into the picture?

More customer insights with continuous research

Firstly, if you want to get closer to your customers you need continuous research. There are two main areas that I believe need to be covered. The first area is feedback from your target audience about your existing product. This means user tests with your product or prototype. Our UX minimum checklist for example suggests at least one user test each week to give you the feedback necessary to build a great product.

The other area is product discovery. Your target group’s unsolved pains and needs will enable you to identify new opportunities. The most common methods uncovering these are interviewing and field research, but diary studies and experience sampling are also good ideas. If you have an existing product I would suggest you try out jobs to be done interviews, which will help you to uncover the real reason that people use your product. In my experience you often get a surprising result which will lead to a rethink of your product’s real goal, and how you develop it further. Product discovery methods often result in new feature or product ideas. For example when we were conducting interviews for a stock trading product, the two major problems that almost everyone mentioned were market analysis and the mental challenges they had. There are many different aspects to analysing market data, and there are many tools to help you too. But the second problem, mental challenges like control of your emotions, is a new and untapped area.

The trick is to do product discovery continuously too. Marty Cagan suggests a dual-track scrum approach. In this method a small part of the team works on product discovery, while the rest work on designing and building the validated feature ideas. If you don’t have that many people you can spend some time with discovery every month and have a strategy meeting in every two or three months to sum up the findings and decide on the direction.

Bring your team closer to your customers

Research is time-consuming, so most teams have separate researcher positions or they work with experienced external researchers. But how can you share all your findings with the design and development team?

The goal is to give the first-hand experience of your customers to everyone in your team. One way of achieving this is to get everyone to do a small amount of support work, a few tickets per month for example. In many companies developers attend a usability test from time to time. In the enterprise world visiting some sales demos can be an eye-opener too.

A great UX design team can help you to facilitate different kinds of workshops. Design workshops can help to align the team and get everyone on board. You can build up your personas or customer journeys together based on the research results.

Ideation sessions can also help. When you discover new user pains the team should come together and brainstorm on features and products to solve them. It’s also useful to hold common sketching workshops when you try to solve bigger usability flaws. You can use the design studio method, which can help you to balance individual and group thinking, giving everyone the time to think about ideas on their own. These workshops usually take just a few hours, but by the end all participants will have better understanding of user pains and possible solutions. They work the best when you invite people with different backgrounds: developers, designers and business people should attend.

Another trick I always use is to put up posters on the office walls. If you want your team to think about different user pains, you can put them up on the wall, so everyone will see them all the time, and in time someone will come up with a good idea.

Showcase customers in your agile metrics

There is no real connection between metrics like velocity and customer satisfaction. You can develop features with a huge number of story points, but it doesn’t mean you solve real customer pains. Some teams drop metrics like velocity, and different estimation numbers and just start to kanbanize their efforts. If you are not ready to do that you can still highlight customer pains in your metrics, and take these into consideration when you prioritise tasks.

One idea is to group the development tasks from your backlog into the following four big categories:

Metrics movers: With these features we can achieve short-term business goals and reassure investors.

Under-the-hoods: Refactoring and rebuilding. These help us prevent technical debt and maintain a good code quality.

User needs: Usability issues and user requests. These improvements will give a sense of quality to our customers.

Strategic, innovative: These features or products can bring us closer to our long-term goals. In many cases solving a newly discovered user pain will be put here.

Have you played with Sims? In Sims you always see your characters’ needs (hunger, hygiene, social, fun), and you have to act if one of the needs bars turns red. Your product is just like a Sims character and these four categories are its needs. Of course we want to focus on user needs and strategic goals, but sometimes you have to take care of under-the-hood tasks too. You can tag each task with one of these four categories, and it will show which area you should focus on now. This will help you to make more conscious decisions when you decide what to do next.

Summary: put customers back in the spotlight

As product managers our goal is to build products that people love. We can’t hide behind methodologies, we should focus on the people we design and build for. So it’s time to take back control. Always keep one eye on customers and never stop doing research. You can choose from the long list of research methods. Build a culture where not just you but everyone is in touch with customers, where everyone knows their pain and tries to solve their problems. And display these efforts in your metrics too. No one said it’s easy, especially in big organisations. But it’s possible, and who else will do it, if not us, the product managers?

]]>http://www.mindtheproduct.com/2016/11/how-to-turn-a-story-point-factory-into-a-customer-centric-team/feed/1http://www.mindtheproduct.com/wp-content/uploads/2016/11/david-pasztor-image.jpgChange or die: what big business can learn from start-ups about internal innovationhttp://www.mindtheproduct.com/2016/11/fostering-internal-innovation-in-big-businesses/
http://www.mindtheproduct.com/2016/11/fostering-internal-innovation-in-big-businesses/#respondMon, 07 Nov 2016 14:21:29 +0000http://www.mindtheproduct.com/?p=9528What’s the single key advantage that start-ups consistently hold over big businesses? One which allows them to move faster, and change course quicker than large corporations? It isn’t talent or creativity, and it’s certainly not resources. Start-up nimbleness comes from employee empowerment – a culture where people at all levels of the organization feel free […]

What’s the single key advantage that start-ups consistently hold over big businesses? One which allows them to move faster, and change course quicker than large corporations?

It isn’t talent or creativity, and it’s certainly not resources. Start-up nimbleness comes from employee empowerment – a culture where people at all levels of the organization feel free to think, behave, control, and improve their work autonomously.

Start-ups have to be agile to survive. Since they aren’t sure what will work in the marketplace, they are forced to try various different angles to find the right way to solve problems, market, and sell. The same cannot always be said for larger, more established companies who have been executing the same way for decades. These companies often struggle to adapt and evolve as they are stuck in the rut of their existing processes, resistant to changes, and have a more rigid decision-making hierarchy.

So how can large organizations take a page out of the start-ups’ book by sparking a cultural transformation from the bottom up, and empowering their workers – as individuals – to make change?

Staying alive

With added competition from millions of new start-ups, globalization and other new-market-seeking enterprises, large organizations lay themselves open to difficulty unless they are open to change. You only need to look at the numbers. In 1958 the average lifespan of a S&P 500 company was 58 years: today the average is less than 18.

The only way to survive is to continuously transform into something else, but many large companies are so focused on upholding and improving their “bread and butter” core business, that they spend no time exploring or experimenting upon other opportunities. Borders went under because they were too busy focusing on selling more books in bookstores rather than exploring the way the market was moving towards the internet, e-readers and a more boutique retail experience.

Of course innovation is important in the corporate landscape, but the idea that it boils down to culture is a new idea. To date, innovation is often left to a chosen few inside labs or incubators, often referred to as the Skunk Works Model, instead of empowering employees throughout an organization to identify and pursue projects beyond the existing business model.

To break out of stagnant processes, and truly motivate a more “bottom up” flow of ideas, I believe corporates need to change their internal structure, and put in place a system where employees are educated, enabled and empowered to think and work in new ways.

1. Educate: Teach your staff a new way of working

A key component of the popular process of design thinking is creating empathy between employees and customers. However, a common problem with this approach is that while teams learn much about their customers, they still fail to take sucessful action on their insights.

One of the first steps to creating a bottom-up flow of ideas is forcing dialogue between teams, offering them insight into parts of the company other than their own, and allowing them to “step into the shoes” of other teams. At established companies you will regularly find that personnel have spent years working in the same job, and have no idea what other departments day-to-day work consists of and how they contribute to creating value for the end customer. The same goes for executives and the C-suite.

At the root of a culture that enables entrepreneurial action amongst all employees is the desire to think independently, and take action to meet an end goal or improve a process, and having the skills to do so. One without the other doesn’t really work. I believe it is important for companies of all shapes and sizes, but especially larger scale enterprises, to educate their individual team members that they ‘can’ and ‘should’ put ideas into action, regardless of whether they are in a management position or not.

Aaron Eden, prior to co-founding Moves the Needle, started a series of successful Lean StartIn workshops which were designed to help teams learn how to use the Lean Startup methodology to rapidly test the viability of their ideas.

Intuit, for example, had been making a big investment into driving innovation. It was certifying internal innovation catalysts and consistently running design thinking workshops. Unfortunately, teams were getting stuck in “empathy land”. They had interacted with customers, but were unsure about how to turn their new-found insights into business impact.

After taking Intuit’s teams through a Lean Startup workshop, Aaron Eden felt that taking them through a rigorous hands-on bootcamp could be the key to turning those insights into impact. In the bootcamps, teams would choose ideas, identify the riskiest assumptions, and run rapid experiments to make decisions and guide next steps with evidence.

In just over 100 days, Intuit was able to help create 100 internal start-ups that generated hundreds of millions of dollars in impact thanks to the insights generated and ideas implemented. Not only were people learning new skills, but they were motivated to turn those skills into action. It started a transformation within Intuit, which is now regularly named as one of the world’s most innovative large organizations.

After teaching employees how to work in a way that supports new value creation, you then have to develop systems and mechanisms that allow and encourage this newfound entrepreneurial spirit to flourish.

Ideas can become severely bottlenecked and new skills wasted if the systems that enable innovation are not put in place. After surveying Intuit employees, Aaron learned that most employees who went through a Lean StartIn workshop felt as if their day-to-day business teams were slow and lacked initiative. They had seen the light, but were back in an environment that was locked into business as usual. At that time, there were no systems in place to exercise the newly developed skills in day-to-day work. Since then Intuit has made strides to identify customer benefit metrics for various teams so that they focus on activities that create new value for their customers.

Humana, the Fortune 100 insurance company, is a prime example of a large corporation that has successfully put systems in place that enable entrepreneurial action.`

Humana was able to move from education into enablement rather swiftly. After doing a series of bootcamps that taught employees how to tactically apply lean innovation methodology to everyday work, the company created a Consumer Experience Lab under the helm of Geeta Wilson. In the lab, developing customer empathy, focusing on their problems and rapidly experimenting with solutions are the norm, not the exception.

The Consumer Experience Lab has created an environment that enables employees to deploy their newly learned skills, and channel their entrepreneurial spirit to unlock massive value. Within the first year they created $10 million in new value for the organization through running experiments on ways to improve customer service.

3. Empower: Transform the culture so the discovery and creation of new value is business-as-usual.

Once employees have the skills and support structure they need to create new value, the final step is to empower employees throughout the organization to act like entrepreneurs.

Empowering employees often involves breaking down the rigid ‘top-down’ hierarchies which are in place. While a company will always need managers, they need to facilitate and incorporate suggestions and ideas from all stages of the ladder, not just the commands coming from above. Providing employees with autonomy — and accountability — makes them more motivated to achieve results, and make positive changes.

Barry O’Reilly, a principal at software design consultancy Thoughtworks, says: “Culture comes from the top. It is up to leadership to define and enact the behaviours that make people feel empowered to innovate and experiment. Pushing down authority is an enabler and empowering teams to come up with their own solutions to solve business problems can give rise to wider innovations.”

Rather than inciting a short-term burst of innovation in the aftermath of workshops, enabling and empowering employees to be innovative should become an integral part of the company’s culture and values.

Innovation through internal mentorship

Even if a team has not gone through a workshop, team members and managers alike should ‘mentor’ and support other members of the team. One means of doing this is by encouraging ‘internal mentorship’ between colleagues.

Established molding company RJG Inc. went through an lean innovation accelerator, where RJG staff were pushed to build customer empathy, run rapid experiments, and make decisions based on evidence. They came up with a new product design after building empathy with their end clients through a series of customer interviews and onsite visits. After continued experimentation they started getting purchase orders and functional prototypes in the hands of customers in under a year compared to the company’s typical six-year product cycle.

Internally, people saw the benefits from working this way and wanted in. People who had never gone through the experience were running experiments while receiving guidance from their more experienced colleagues.

The new way of working was not merely becoming the norm for a select few, but rather the entire business culture was shifting. Employees didn’t feel the need to seek out permission to run experiments on new ideas because the culture empowered them to do so.

Some large companies are going a step further to demonstrate to employees that they are able to, and encouraged to be innovative.

Adobe rolled out the “Adobe Kickbox” program, which offers any employee the chance to be an innovator. As part of the scheme, employees get access to a ‘kickbox’ — a red paper box containing $1,000 of seed money, instructions for Adobe’s six-step innovation process and other innovation tools – that intrapreneurs are free to use to test new product ideas.

Since rolling out the scheme, Adobe has handed out more than 1,000 red boxes to employees around the world. By focusing on the people, and not the outcome, Adobe has found a means of incubating thousands of new ideas from within. Other large companies like Mastercard have since followed suit.

While offering cash to each employee might not be the right answer for all companies there is a lesson to be taken from Adobe’s plan. Using the idea of “educate, enable, empower”, all large-stage companies can break down the internal barriers to innovation by showing every employee that their they really can make changes, and put great ideas in motion.

Corporate leaders know their organizations must move faster, be more agile and act bolder. But just saying it, doesn’t make it so. Trumpeting “be bold!” without fostering an environment that makes it safe to work differently results in fear, not innovation.

]]>http://www.mindtheproduct.com/2016/11/fostering-internal-innovation-in-big-businesses/feed/0http://www.mindtheproduct.com/wp-content/uploads/2016/11/innovation.jpgWhen the price is right: managing price segmentationhttp://www.mindtheproduct.com/2016/11/when-the-price-is-right-managing-price-segmentation/
http://www.mindtheproduct.com/2016/11/when-the-price-is-right-managing-price-segmentation/#respondTue, 01 Nov 2016 10:30:58 +0000http://www.mindtheproduct.com/?p=9362Is price segmentation fair? One of the most valuable levers a company has when pricing its products is charging different customers different prices, also known as price segmentation. In essence, a company estimates a buyer’s willingness to pay and does its best to charge as close to that as possible. Of course, there is no […]

Is price segmentation fair? One of the most valuable levers a company has when pricing its products is charging different customers different prices, also known as price segmentation. In essence, a company estimates a buyer’s willingness to pay and does its best to charge as close to that as possible.

Of course, there is no way to tell precisely how much a buyer is willing to pay. So instead companies use different statistics and techniques to divide up the customer base and ensure that those willing to pay more actually do. There are four main ways that companies do that: customer characteristics, transaction characteristics, behaviours and product portfolios. But the question is, is this really fair?

What is fair?

Fair is in the mind of the buyer. If a buyer thinks it’s fair, then it is. On the other hand, when a buyer, or more importantly, when a lot of buyers, think it’s unfair then it’s a problem. In the early 2000s, Amazon used zip codes to help determine the price it would charge. People in wealthier areas were shown higher prices than those in less affluent areas. As a price segmentation scheme, this works exceptionally well, but when this was discovered and published, the outcry was huge. Amazon does not do this anymore.

Price segmentation techniques

The question of fairness really differs depending on the segmentation technique used. Let’s take a look.

The first technique is customer characteristics. You have likely seen these as senior discounts or student discounts. It is also quite common, although Amazon found it to be a problem, to see these based on geography. For example, if you live in Florida you get a discount at Disney World. To make this feel fair to customers, set a high list price and then offer discounts to a specific group. As long as most people find that group reasonable, then they will see it as fair.

A word of caution – there are certain customer characteristics, such as race, that should never be used for price segmentation. And while gender is sometimes used, for example for insurance or ladies night at a bar, be cautious here as well.

Transaction characteristics are what you can learn at the time of the transaction that will help you understand your buyer’s willingness to pay. For example, buyers who need it as soon as possible probably have a higher willingness to pay. Weather, season, day of week, time of day and purchase volume can be characteristics that may drive or indicate willingness to pay. Companies may offer a discount to a sporting event if the weather is bad for instance. Or they may offer discounts on winter clothes as spring approaches.

How you present the differing prices matters though. Gas stations in the US used to have a 2c surcharge if customers paid with a credit card. They got a lot of push back; it didn’t seem fair. Now they offer a 2c discount if customers pay with cash. It’s the exact same thing to the company, but to the market one looks fair and one doesn’t. As with customer characteristics, in most cases you are better off setting a high list price and then offering discounts.

The third technique, behaviours, is about putting hurdles in front of buyers so they have to prove they are price sensitive. The easiest example of this is coupons. Some people use coupons, some don’t. Those who do are more price sensitive. They are willing to invest the time and energy to find and use the coupon. That’s the hurdle. As long as everyone has the ability to find and use the coupons, this technique is seen as fair.

The final method for price segmentation is creating a product portfolio to get different buyers to select different products. First class versus economy class on an airplane is a great example. People pay a lot more for first-class seats even though it’s essentially the same experience as coach just with a little more room and a meal. By creating a different product, the airlines could get one segment to pay them significantly more. Creating high-end versions of products and charging more for them is typically seen as fair.

The problem with fairness and product portfolio pricing arises around race and gender. A department store had two identical versions of a baby doll except one was black and the other was white. So far that’s OK. The problem was they were charging two different prices. It doesn’t even matter which one was more expensive, there was no way that would be seen as fair. (And the problem was fixed as soon as the store found out.)

As a whole, women’s products are more expensive than men’s products. And while we’ve seen stories pop up in major new outlets about this periodically, any uproar around the topic seems to die out quickly. That’s because often product pricing is defensible in this regard. For example, deodorant for men and women costs about the same to make, but women’s is more expensive on average. However, because they are clearly different products with different brands it seems to be accepted. The bigger problem comes when the products are essentially the same except for colour or packaging. A department store (luckily not the same one) had two nearly identical bicycles, one blue the other pink, priced at two different prices. This is pretty hard to justify and it is easy to see why buyers found it unfair.

Just because we can, does that mean we should?

The good news is that buyers all over the world are used to seeing price segmentation. They have learned to accept most of it as fair. This gives companies a lot of leeway to charge more to some customers than they do to others. However, you want to be vigilant to stay on the good side of your customers, to make the price segmentation seem fair. The best advice to achieve this: put yourself in the shoes of each type of buyer. Would that buyer think it’s fair?

Just because we can segment on price, doesn’t mean we should. But if we don’t do it at all, or don’t do it well, we leave a lot of money on the table. Segment carefully.

]]>http://www.mindtheproduct.com/2016/11/when-the-price-is-right-managing-price-segmentation/feed/0http://www.mindtheproduct.com/wp-content/uploads/2016/10/price-segmentation.jpgHow aligning product and marketing teams improves customer experiencehttp://www.mindtheproduct.com/2016/10/how-aligning-product-and-marketing-teams-improves-customer-experience/
http://www.mindtheproduct.com/2016/10/how-aligning-product-and-marketing-teams-improves-customer-experience/#respondThu, 27 Oct 2016 09:16:39 +0000http://www.mindtheproduct.com/?p=9432It wasn’t too long ago that designers and developers were disciples of strictly separate crafts – but today, someone who can do both well is quickly labelled a “unicorn”, and sought after by many a unicorn-thirsty start-up. I believe the same synthesis of skill sets is occurring between marketers and product managers, but all too […]

It wasn’t too long ago that designers and developers were disciples of strictly separate crafts – but today, someone who can do both well is quickly labelled a “unicorn”, and sought after by many a unicorn-thirsty start-up.

I believe the same synthesis of skill sets is occurring between marketers and product managers, but all too often, they’re treated organisationally as separate disciplines, broken up into siloed teams. It’s a common-sense approach, but customer attitudes are shifting significantly, which means there’s a growing need for both teams to get each other’s backs in order to effectively deliver a seamless customer experience. To quote Adaptive Path co-founder Peter Merholz from this blog: “The experience is the product.”

I’ve worked on the teams of several SaaS products in a dual marketing/product management capacity, and have seen first-hand the overlapping work that exists between crafting a compelling brand, and building a product that people love. In doing so, I’ve witnessed the benefits gained when a cosy relationship develops between marketing and product teams, especially in fast-moving start-up environments.

Easier said than done though, right? I’d like to share some practical ways that I’ve found invaluable to get marketing and product people pulling in the same direction, and in doing so, nailing objectives for the business.

But first we must ask ourselves: why?

Why Marketing and Product must work together

We’re all familiar with some variation of the traditional linear marketing funnel. The pyramid that starts with Awareness/Acquisition, and ends with Loyalty/Retention?

It’s becoming a less and less reliable model for how customers actually engagewith brands and businesses. As traditional marketing messaging is increasingly met with distrust, consumers are now empowered by their smartphones and mobile connectivity to find and engage with businesses at almost any stage of the marketing funnel. As long ago as 2014, the Harvard Business Review was talking about how marketing can no longer rely on the funnel.

Now, if all your marketing resources are concentrated at the Acquisition stage, it’s either not reaching or is irrelevant to those people who’ve already moved on to later stages in the funnel.

But, there is an alternative model, devised by consulting firm McKinsey, that gives us a bit more insight into today’s consumer behaviour: the Loyalty Loop.

The Loyalty Loop articulates how today’s consumers form relationships with the brands they do business with. It demonstrates that they’re highly likely to stay loyal to the brands which deliver them the best end-to-end customer experiences – from initial consideration, through to post-purchase use of the product or service, and back around to subsequent purchases.

The Loyalty Loop means that competitive advantage has shifted to those businesses that retain the most customers, instead of the ones that gobble up the most new customers – which in turn means the responsibility for providing a great customer experience falls upon both Marketing and Product teams, equally. Retention has become everyone’s top priority.

Now, we know that Product has key insights into customers’ preferences that could help Marketing propel them around another buying loop. Likewise, Marketing has the inside scoop on what excites and engages users and turns them into customers – so let’s look at some practical ways we can get that kind of seamless collaboration going.

How to align Marketing and Product

1. Give them common objectives

One easily-implemented way to incentivise the dissolution of barriers between Marketing and Product teams is to give them (or advocate for) common objectives and KPIs to go after – to have them succeed and fail as one team.

For example, let’s say you have your marketers and product team set a common goal to reduce your product/service’s churn rate to 5% this quarter. Your product team can inform your marketers about the characteristics of those customers who tend not to churn, thus helping them to tailor their messaging to that audience. In the meantime, the product team could be prioritising bug fixes and new features that tackle the churn problem head-on – and which gives the marketing team even more fodder for compelling announcements to customers.

Last year, during my time leading the team behind a blog analytics platform called Filament, our objectives were often focused on quarterly revenue goals. Our marketing and product teams collaborated closely by pursuing multiple strategies at all stages of the funnel, in order to maximise our chances of reaching them:

Increasing traffic and sign-ups – Our product team often heard that our customers loved being able to see which influencers had shared their content, so our marketing team prominently displayed that feature on the home page, which drove more sign-ups

Launch and upsell new features – By sharing ongoing product development updates with the marketing team, we were able to keep our existing customers engaged and upsell them to additional features and apps as soon as they were launched

2. Speak the same language

Agreeing to a common language and standardised internal jargon when it comes to talking about customers is effective for removing the friction from collaboration between your teams, and provides a few key benefits:

It gets the teams thinking about the typical customer’s whole journey as they pass between marketing and the product

It reduces confusion between the teams, and gets them considering the same customer/user personas when making decisions

It makes it easier for product teams to share insights back to marketing on how customers behave after acquisition

I personally experienced this kind of friction on a product where there was a clear disconnect between the marketing and product teams’ definitions of an engaged user:

Marketing

Signed up

Logged in 3+ times in the last 30 days

Product

Signed up

Installed code snippet on their website

Visited 3+ screens in the product over the last 30 days

This disconnect caused mass confusion whenever we wanted to know how many engaged users we had, and several times, it resulted in the teams pursuing conflicting priorities. A single meeting was all it took to hammer out a meaningful, commonly-understood definition that eliminated the confusion, and allowed the teams to see their impact on the shared objective of growing user engagement.

3. Everyone does customer support

The very best feedback comes from sitting face-to-face with your customer – it gives you the richest, most in-depth feedback upon which game-changing hypotheses get validated or broken. After all, how can you develop a mutually satisfying relationship with someone, when you never communicate with them directly?

Everyone develops an innate sense for what customers need, and how those needs apply to their specific roles in delivering the customer experience

Response times go way down, which means happier customers

Marketers get a deeper understanding of how their messaging should adapt to customers’ needs at every stage of the business funnel

There are fewer disconnects between what marketing is promising and what the product/service delivers – which can actually reduce pre-purchase support inquiries

Roping in people from our product design and marketing teams to handle frontline customer support tickets inspired a major redesign of my past blog analytics product, Filament, as the same question kept coming up from our users while they looked at their analytics reports: “So… is that good, or bad?”

We began gut-checking the redesign of our analytics reports to ensure they were clearly answering this simple question – and the improvements we saw started finding their way into our marketing messaging: “Know at a glance how your content is performing”.

Find a way to carve out time for your marketers and product people to rotate through customer support, and I think you will be amazed at the ideas they generate as a result.

4. Everyone has a say in the whole customer journey

What do I mean by this? If your customers’ experience through your business’ Loyalty Loop is to be seamless, it helps if everyone involved in constructing and managing that experience understands the full context of their work.

Have representatives of your marketing and product teams (and others) collaborate on an experience map to fully understand – from multiple perspectives – the pain points where your customers’ needs or expectations aren’t being met. Good ideas can come from anywhere in your business, so give your teams the opportunity to tackle dips in the customer experience from their own perspectives.

While building and scaling various SaaS products, the products team at Digital Telepathy, (of which I was a part), leveraged elements of experience mapping, as well as the intensive Design Sprints methodology pioneered by Jake Knapp and John Zeratsky at Google Ventures, in order to walk through our users’ experiences step-by-step. We used insights from this discovery process to identify our users’ wants and needs at each stage, then rapid-prototyped and tested solutions to create a more seamless transition between marketing and actually using the product.

In summary: seek alignment between Marketing and Product

A great end-to-end customer experience is becoming an expectation of today’s customers, and the only way to provide this is through tight alignment between Marketing and Product teams.

Having both teams pulling in the same direction confers massive benefits to your product, including:

Stronger retention (and the associated competitive advantage)

A more seamless customer experience

Greater focus on more impactful work, instead of chasing vanity metrics that don’t actually help the business

Less redundant work – Marketing knows things that can make Product’s life much easier, and vice versa

To get that elusive alignment between your teams, treat them like they’re a single team. Remember, “The experience is the product” – so set shared goals, remove any barriers to collaboration between marketing and product, and get both teams some direct facetime with your customers.

]]>http://www.mindtheproduct.com/2016/10/how-aligning-product-and-marketing-teams-improves-customer-experience/feed/0http://www.mindtheproduct.com/wp-content/uploads/2016/10/rowing.jpgWhat makes effective decision making so challenging for product managers?http://www.mindtheproduct.com/2016/10/what-makes-effective-decision-making-so-challenging-for-product-managers/
http://www.mindtheproduct.com/2016/10/what-makes-effective-decision-making-so-challenging-for-product-managers/#commentsWed, 19 Oct 2016 09:05:36 +0000http://www.mindtheproduct.com/?p=9334How can a product manager make effective decisions about the direction of their product? How do they adequately weigh up all the variables to select the best solution from the available options? And how do they make sure that any investment will adequately consider future movements of both the market and the competition? The pressure […]

How can a product manager make effective decisions about the direction of their product? How do they adequately weigh up all the variables to select the best solution from the available options? And how do they make sure that any investment will adequately consider future movements of both the market and the competition?

The pressure is on to get it right

Why should product managers be under any more pressure to make sound decisions than finance managers or sales and marketing teams? It’s a question of responsibility:-

Firstly, product managers should look to own the success of their products, including the commercial and customer satisfaction performance. While marketing and sales teams are stakeholders and involved in achieving the targets, it’s the product manager who is absolutely committed to delivering the revenue, profit and satisfaction targets.

Second, the product manager’s delivery requirements will usually be the big development items in an organisation’s technology roadmap. As such, the majority of the organisation’s development, roll-out and training effort will be spent implementing activities directed by the product manager.

Thirdly, it’s the product manager who should watch for strategic movements in the market and among competitors, and who should attempt to keep one step ahead.

So in this light, every terrible decision that businesses have made can ultimately be handed to the product manager – the New Coke launch; Blackberry and Nokia missing the development of the mobile market; Yellow Pages being so slow to pick up on digital marketing.

The theory’s great, but…

But there are many sources of advice on decision making. I think the Wikipedia entry on decision making, for example, is impressive, and it lays out a broad range of options. A previous manager of mine used to quote Kurt Lewin’s statement “there’s nothing so practical as good theory”, but this is of little comfort when faced with problem with no obvious solution. I hope I’m not the only product manager who’s been working on a critical business turn-around product only to find that focus groups have explicitly stated it’s not good enough for them to want to change their current service.

So why is decision making so challenging? It seems to me that the problems for a product manager come from three main areas:

Incomplete understanding of market or competitors. Making a decision without knowing the impact on our core customer segments (B2C) or our biggest customers (B2B) means we will be at risk of delivering something that is perhaps irrelevant or irritating.

Unreasonable costs and timeframes to deliver. Why does technical implementation force us to write requirements and decide a proposition and pricing six to nine months before we’re going to launch? It’s inevitable that the market and customer needs will change in this time and that system development teams won’t want or be able to handle changes easily.

Inability to see the future. I’m not sure there’s much I can add to this one.

There’s an additional challenge that deserves special mention – that of attempting to meet unrealistic expectations. Whether these expectations are about functionality, timescale or cost, it’s always challenging to ensure that what is launched is as good as the original concept appeared to be. I’d argue that this expectation setting is always within a product manager’s gift to control, and is the most powerful element in determining success.

Expectation management is so important because the product manager must decide the compromise on the functionality / cost / time equation, while ensuring the product/market fit remains strong. Such compromise decisions arise from new information from the market, suppliers, development teams or product testing, and happen throughout a project.

The judgement call about a major change in product features will determine whether the internal and external audiences need to be updated. While it may be painful to revisit all the stakeholders to explain a change about product delivery, functionality or cost, this is the only way to ensure the business stays committed to the product.

It’s also a valuable opportunity to ensure that you are still on track to launch a successful product that meets your customers’ needs; whilst it is a difficult decision, the product manager must be able to understand when the product no longer achieves the core outcome targeted and, as a result, facilitate a decision as to whether to kill the initiative.

Selling “ahead of the curve”

More challenging is to ensure that the rest of the organisation sets internal and external expectations that align with the product reality. It’s almost inevitable in a B2B environment that sales teams will look to ‘extend’ what your solution can do in order to close the sale. This can be avoided by getting the product manager involved in customer prospect conversations and using these conversations as opportunities to validate the product’s direction. When this isn’t possible, it’s critical that sales teams are given factual and accurate views of what the product will and won’t do and that they are held to account if they deviate from this.

But there are always scenarios where business leaders will choose position over content; a recent example for me is where press have been informed we’re launching a product before we’ve even proven the solution works. I’ve also had the interesting situation where the CEO of the organisation has announced the pricing of a product (“it’ll be absolutely free for our existing customers”) at our all-hands company meeting, in front of 2,000 people. It wouldn’t have been so galling if I hadn’t had spent hours preparing the pricing recommendation I was due to make the following week.

It’s about collaboration, not going it alone

So how do product managers make good decisions? Well, after all this build up, I’m afraid you may find that the answer is rather mundane: it’s just like making a decision anywhere else.

Unless you’re the owner / manager of your own start-up, successful decision making is all about collaboration and ensuring the right audience has input into decisions. And even if you’re launching your own business, you need a ‘board of advisors’ who can guide you whether the approach you are taking is correct.

The ultimate decision makers who direct the product are dependent on the business. And your job as a product manager is to absolutely drive them to make the right strategic decision for the business.

One of my past roles involved me fighting tooth and nail within a large multinational service business to expand and massively upgrade its SME product, both to augment the customer experience but also to close out the competition. Despite everything I tried, and the evidence supporting my decision going to the board, the leadership team chose not to pursue it. That business is now losing approximately 7% year-on-year share to more nimble, flexible businesses that realised the margins were attractive and customers weren’t being serviced effectively.

Could I have done anything more as part of the decision making process? I’m convinced the answer is no. Whether I liked the outcome is a different matter.

]]>http://www.mindtheproduct.com/2016/10/what-makes-effective-decision-making-so-challenging-for-product-managers/feed/1http://www.mindtheproduct.com/wp-content/uploads/2016/10/decision-making.jpgTesting and revising contact forms to improve conversion rates – a case studyhttp://www.mindtheproduct.com/2016/09/improving-conversion-rates-a-case-study-in-contact-form-testing/
http://www.mindtheproduct.com/2016/09/improving-conversion-rates-a-case-study-in-contact-form-testing/#respondFri, 30 Sep 2016 09:10:43 +0000http://www.mindtheproduct.com/?p=9198Have you ever spent months testing and optimising a site and still found yourself falling short of targets? Or ever felt that your site satisfied CRO best practice and been unsure how to get the additional conversion boost you need? What do you do next? How about throwing best practice out the window and adding […]

Have you ever spent months testing and optimising a site and still found yourself falling short of targets? Or ever felt that your site satisfied CRO best practice and been unsure how to get the additional conversion boost you need? What do you do next? How about throwing best practice out the window and adding 37% to revenue per form visit?

The Scene

VouchedFor is a rate and review site for financial advisers, accountants and solicitors – think TripAdvisor for professional services. A key offering of the service is allowing consumers to contact a professional through the site. After a site redesign and several months of intensive conversion rate optimisation, our focus was on the last step in the funnel; the contact form.

Two months running A/B tests to optimise contact forms had had a positive impact, with several tests producing significant uplifts in conversion rate including, for example, a 29% increase in form completion rate through a button wording change.

However, while satisfying most conventional best practices, conversion rate of the form was short of the target the team believed was achievable, and worse, we were running out of ideas. We were left with the following options – accept defeat and shift focus to a different area of site; continue down the path we were on with increasingly niche refinements or go back to the drawing board and come up with some great new ideas.

With a form that satisfied all of these and more, we were starting to run out of inspiration for what we should do next.

The Original (Control) Form

Around 30 A/B tests had resulted in the following form:

Every element on the form had been tested at least once, with many having been through multiple variants that led to this design, and when compared with a best-practice checklist it scored pretty well.

The Insights

To gain an understanding of why this wasn’t working as well as we thought possible we focused our research efforts on our users. User research had highlighted that consumers were intimidated by financial advisers and concerned about coming across as uninformed when communicating with them; field-level Google Analytics data showed that, after those who exited the form without starting it, the highest drop-off stage of the form was the free text enquiry box; Inspectlet recordings showed users having issues with this area of the form, with many starting, deleting, retyping and finally abandoning this section.

Previous tests which changed the ordering of the form had made little difference to the completion rates of the different fields, with the enquiry message consistently the stage with the highest drop-off rate.

This enquiry message was a key business requirement as part of the offering to financial advisers, so removing it from the form wasn’t an option. Any future form would have to have a text box for users to include any important information about themselves.

The Hypothesis

Users find it easier to answer direct questions than to fill in a free text enquiry due to uncertainty over what to say and a fear of coming across as uninformed.

The Caveat

More than one variable was changed at the same time so this wasn’t the perfect test. However the insights gained from the test are still valid when considered in total.

The Tests

We decided to try a different direction. Instead of pursuing the concise version preached in the best practice guides, we decided to ask the user to supply much more information through a series of direct questions in the hope that users would find it easier to answer these types of questions than the enquiry box. If we could capture key information this way then it would reduce the importance of the enquiry box.

Test 1

A/B test of a new form (Variant A) against Control. The key differences between the Variant A and the Control were:

Increase the number of fields, with up to 15 questions asked on the new form depending on the service selected

All new questions required either a numerical answer and/or allowed the user to choose from some given options

Use radio buttons or segmented controls instead of dropdowns

Increase form length from 1 to 5 pages

The Result

As you might expect, Variant A performed worse than Control with a conversion rate 14.5% lower. However, some of the data suggested that it wasn’t worth abandoning the hypothesis just yet.

There were two stages on Variant A with a high drop off – the first page, where users were asked to select a service to receive advice on, and the last page, where the user was asked to complete the enquiry form.

More surprising were the data points where Variant A outperformed Control. Stages 2, 3 and 4, where users were asked to provide their contact information and answer the detailed questions about their finances, each had a drop off of less than 10%. This meant that users who selected a service on Variant A completed the form at a very similar rate to users who selected a service on Control, despite having been asked to provide significantly more data.

The Next Insight

Users struggle to identify one single area on which they need financial advice. Often they need advice in several areas or aren’t able to answer a specific area. The fear of coming across as ill informed or of misleading an adviser by selecting the incorrect service was deterring people from choosing one service. Once again this was backed up by Inspectlet recordings showing users struggling to settle on one service.

Test 2

A/B test of a new form (Variant B) against Control. Variant B built on Variant A with the following amendments:

Allow users to enter more than one service on the first page

Pre-populate the enquiry message with information gained from the questions the user had already answered, and give the user the opportunity to amend and add more information to the message.

The Result

A significant improvement in first page completion rate (65% higher than Variant A) and an improvement in the completion rate of the enquiry form (8% higher than Variant A) led to a much higher form completion rate – 15% higher than Control and 36% higher than Variant A.

The majority of users edited or added to the pre-populated enquiry message.

Test Data

Overall Result

A 15% increase in conversion rate and an increase in revenue per enquirer thanks to better matching of consumers with advisers due to the additional data provided by users led to an increase of 37% in revenue per form visitor.

What’s more, the device category with both the biggest relative improvement and also now the highest absolute conversion rate was mobile.

The Learnings

1.Longer, more detailed forms asking the user for more information can increase conversion:

Users were more likely to complete a five-stage form with multiple detailed questions than they were to answer a short one-page form.

Users who were able to add more than one service converted at a much higher rate

Free text boxes are scary, particularly in a subject matter with high knowledge levels. Consumers find it easier to answer direct questions. When enquiry messages are required, giving the user a helping hand by suggesting what they could write helps.

Understanding users’ demand is as important as a great user experience and satisfying “best practice”. Gear conversion forms towards how the user is thinking, not the way you think about the questions.

The So What?

The internet is full of information about how to optimise conversion rates. Every major product, marketing, ecommerce and CRO blog contains articles on how to improve site conversion, many promising huge uplifts if you follow what they say. At times optimising a site can feel like a box ticking exercise, with success ensured if you stick to the recipe prescribed elsewhere.

I hope our experience can help serve as a reminder that, as with all areas of product development, the right solution for your product could be completely different to the one that works for others, and the only way to find it is by putting your users at the core of whatever you’re making. Best practice articles can be a good way to get inspiration but they’re not guaranteed to be the right answer for you.

]]>http://www.mindtheproduct.com/2016/09/improving-conversion-rates-a-case-study-in-contact-form-testing/feed/0http://www.mindtheproduct.com/wp-content/uploads/2016/09/form-filling-2.jpgUsing Pricing to Inform Your Roadmaphttp://www.mindtheproduct.com/2016/08/using-pricing-to-inform-your-roadmap/
http://www.mindtheproduct.com/2016/08/using-pricing-to-inform-your-roadmap/#respondFri, 26 Aug 2016 13:03:04 +0000http://www.mindtheproduct.com/?p=9034We often think of pricing as something to do right before launching a new product. Maybe it gets a little thought during development, but it isn’t urgent. Now that we’re approaching launch though, we need a price. Or, sometimes we schedule a pricing meeting to decide whether to change our existing price or, albeit rarely, […]

We often think of pricing as something to do right before launching a new product. Maybe it gets a little thought during development, but it isn’t urgent. Now that we’re approaching launch though, we need a price.

Unfortunately, these pricing conversations occur too late in the process. To create more profitable products and product portfolios, we must incorporate pricing concepts from the outset.

More profitable products

Of course, you want buyers to choose your product instead of your competitor’s product. So you need to know how your buyers decide between the alternatives.

Price is almost always a factor in such decision making. If your product is more expensive than your competitor’s product, people will only buy it if it offers more. But more what? That’s what you need to figure out because every time your buyer decides between you and a competitor, this is how they make the decision. Which one costs more? And is it worth it? “Is it worth it” is all about differentiation.

You must find out what buyers are willing to pay for that your competitors don’t have, then put that in your product. This is differentiation that is extremely valuable.

As a product manager, you have a long list of features to build or market problems to solve. You need to prioritise them. One factor should be willingness to pay. How much more would buyers pay for this feature or solution? Hence, the most valuable differentiators should come earliest on your roadmap.

More profitable product portfolios

So you now know that once you decide which product to build, you have to build in valuable differentiation. But how do you decide which product to build?

Companies rarely launch new products in new markets. So your next product will probably be targeted at your current markets and maybe at even your current market segments. You know these buyers and users well. You also know what unsolved problems they have. You are in essence building a product portfolio: multiple products targeted at the same market.

There are two basic types of products in a portfolio: versions and add-ons. You may have heard your economics professor call them substitutes and complements. Versions are the products your buyers are deciding among. Think good, better,best versions of a smartphone. Buyers tend to buy only one. Add-ons are the options people buy in addition to the base product. Think accessories or apps for that smartphone.

It is critical that we understand how people make decisions within our own product portfolio. That will drive us to more profit. Let’s look a little more at versions and add-ons and how they can influence our roadmaps.

Versions

There are two powerful ways to use versions in your product portfolio. The first is to build different versions for specific market segments. Look across your current customers. Some probably derive more value from your product than others and would pay significantly more, but you couldn’t charge more because you still wanted to sell to the other customers.

If this is true – and it usually is – consider creating a different version of the product for this new market segment. For example, Evernote’s premium version, which targets individuals, sells for $69.99 per year. Its business version costs $12 per user per month, or $144 per person annually. Of course, there are some differences between the products, but the main one is that each version targets specific market segments that have a different willingness to pay.

The second powerful way to use versions is to build good, better and best versions. Too often, companies build base products with complex options and price books that are so confusing buyers can’t decide. And confused shoppers don’t buy. So once you identify the market segment, then create good, better and best versions for buyers in that segment.

Put yourself in the mind of your buyer and how they make this decision:

If they know exactly what they need, they buy that.

If budget is their primary consideration, they buy good.

If the product is just a small portion of their spending budget, they buy best.

Everyone else — the vast majority — buy the one in the middle: better.

Having three versions of your product helps you win more customers. First, having a good version allows you to attract customers who might not otherwise afford to buy. Next, you can nudge the purchase of most buyers into better, a more profitable product for you. Finally, customers who aren’t price sensitive buy best.

You should intentionally plan to build versions, both across market segments and within market segments, and the effort should influence the products and features on your roadmap.

Add-ons

Acquiring customers is challenging and expensive. So once you win a customer, you want to maximise their lifetime value. A great way to do this is through add-ons.

You can create options for your product that buyers will pay you for. Those options tend to have higher prices and hopefully higher margins because your customers are locked in. Think about why popcorn is so expensive at the cinema: once customers are inside the theatre, they don’t have many other choices.

Of course, it’s important not to make this too complex. A good rule of thumb is to only create options or add-ons for items that have significant value (i.e. high willingness to pay) to a small portion of your market.

Think about what more you can sell to your current customers now that they trust you. These solutions, like all good product ideas, should go on your roadmap.

The most profitable products and product portfolios are created only after you understand pricing. Knowing how your buyers use price to make decisions is critical. Understanding how different buyers use price is also important. Once you internalise this, you’ll find it informs your entire product roadmap. After all, pricing is much more than simply placing a number on a product.

]]>http://www.mindtheproduct.com/2016/08/using-pricing-to-inform-your-roadmap/feed/0http://www.mindtheproduct.com/wp-content/uploads/2016/08/market-prices.jpgTurbocharging Product Developmenthttp://www.mindtheproduct.com/2016/04/turbocharging-product-development/
http://www.mindtheproduct.com/2016/04/turbocharging-product-development/#respondMon, 18 Apr 2016 13:26:29 +0000http://www.mindtheproduct.com/?p=8308In the eternal debate over in-house teams or external agencies, everyone is obsessing over the politics of either-or, when they should be focusing on the end goal: the best possible services. And that can only come from an intelligent combination of both. Outsourced Step-Change For many years, we were employed by clients to undertake periodic […]

In the eternal debate over in-house teams or external agencies, everyone is obsessing over the politics of either-or, when they should be focusing on the end goal: the best possible services. And that can only come from an intelligent combination of both.

Outsourced Step-Change

For many years, we were employed by clients to undertake periodic design ‘updates’ to their sites, apps and services. We’d conduct a rigorous design process and deliver a step change in that service’s performance.
The pattern of that service’s development looked something like this:

The net result was that over time, the service got progressively better. Each major design update gave it a new lease of life, and by involving customers in that process, we could at least ensure that it was fuelled by genuine customer insights. That, alongside some evaluation of performance data, got us as close to the customer and the operational realities of that service as we could.

In the intervening periods, nothing much changed. Our clients ‘ran’ their services based on the last design update. They invested little in them and rarely made the incremental changes that can only come from understanding the behaviour of a service and its customers on a day-to-day basis.

It probably appeared to customers somewhat like the way cars are still released into the world: interim refreshes are released fairly frequently to maintain competitiveness and sales performance, with major new model releases every few years to reset and reposition with a big splash. Over a decade, each car model gets substantially better – by way of relatively big steps, taken relatively infrequently.

Except, unlike cars, digital services need to adapt much more frequently and are subject to an infinitely more complex set of competitive and behavioural influences – in much shorter timeframes.

To respond to the nuances of those influences, the small changes made frequently, you need to be close to the service day in, day out. Today, that role often falls to product owners or product managers.

Back then, we frequently nagged our clients to hire in-house teams; to take ownership of their services and to see them as living entities, not static operational releases. They needed to own their own products.

We knew that we, as an external partner, could never play the role of product owner, nor should we. We declined retainer-based relationships on that basis, as we knew we’d be bad at them: we simply would not be close enough to the performance of the service concerned, or integrated tightly with the operations of the organisation that owns it, to make frequent, iterative changes to it. Our role was to facilitate the big steps.

In-House Evolution

Over the last decade, we’ve seen a slow, steady increase in the number of organisations who have hired in-house UX/design/product teams, to the point where now there’s almost a ‘mine is bigger than yours’ competition going on among peers. But politics aside, organisations now realise the importance of evolving their products in response to continuous market movements, and have invested in bringing those skills in house.

There are now, finally, teams in place that can deliver steady, incremental improvements to products and in many cases they have an influential seat at the leadership table too. The development of a typical product now looks like this

The big advantage this has over the old model is that there is no hiatus period between launches. Even though the peaks are not always as high at a single point in time, customers get continuous improvement to their services (when the product team works well of course) and you can certainly argue that as a result it leads to a better customer experience over a given period of time.

Great internal product teams get really close to the needs of their customer and their organisation and respond to them quickly and continuously. They can act to address a slight decline, to respond to a competitor’s new feature and to capitalise on a success. Their closeness to their product allows them to optimise and refine it in ways that we, as an external partner, could never do. No matter how well we know them and the product, we’re simply too detached from their day-to-day to deliver that kind of continuous incremental change.

The interesting change this has brought about is an overall lifting of standards across whole sectors: customer experiences get better on average as multiple organisations iterate their products more frequently in response to each other. Look in almost any established sector that has built in-house capability and you’ll see this overall raising of experience standards.

Competitive Convergence

And that’s where things are getting interesting. Because that pattern is also leading to smaller margins of difference between competitors: they are literally becoming more and more alike as they learn more and more about a typically shared or similar customer base… and each other. Standards seem to rise in almost direct correlation to similarity, and that’s starting to cause all sorts of new problems, most of which should be blindingly obvious. Put simply, it’s harder to differentiate when the differences are – in every sense – small. And it’s progressively harder to step back far enough that you can see how to.

Think about any established digital sector these days and you’ll see this playing out. Price comparison, flights, travel, ticketing, gambling, restaurant booking, messaging, property… the differences between services in any given sector get progressively smaller as they become more evolutionary in their approach.

Ironically, it’s a flaw borne as much of customer-centricity as it is an obsession with peers. In any given sector, customers are most likely to be able to articulate differences; typically based on their preferences from other services in the peer group. “Their calendar is much easier to use”, or “I like it. It’s more like theirs and I think theirs is the best” are two of a thousand similar ‘insights’ that are gleaned every day from customer research that are fed into incremental design improvements, and consequently to increasingly convergent experiences across competitors.

Let’s think back to the old stepped model for a moment. Interestingly, it didn’t suffer from this problem. For its weaknesses in continuous improvement, it did allow organisations to assert their difference more effectively, at least for a period of time. Each time we worked on one of those big step releases, we came to it with fresh perspective (not least because we’d worked on a variety of other things in the interim) and could often see both gaping flaws and glaring opportunities that could be capitalised on.

Both approaches work for some things, and fail for others.

Turbocharged Evolution

Fortunately for all of us, there’s an obvious answer. The more enlightened organisations are realising (to be fair, some always knew) that this is not an either-or choice. They’re recognising that the only way to build any form of substantive market advantage is to combine both.

Instead of comparing the stepped approach against the continuous one, look at what happens if you combine them effectively.

It’s really not rocket science. Combine the two and you end up, at any given point, far ahead of either approach in its own right. Step changes are like a turbo boost for product evolution in the same way that periodic ‘mutations’ are increasingly believed to lead to major acceleration phases in biological evolution – albeit in rather less predictable ways.

In mature sectors, this is common. Car companies buy in external design studios frequently to help their (often very talented) internal teams challenge assumptions and take bolder steps forward. Technology hardware companies run large in-house teams and buy in design at some of the highest levels of any sector. FMCG companies have long had internal creative teams, and they buy in help for major refreshes or launches. All highly competitive sectors, and there are hundreds more. Imagine how many large corporations there are today with equally large, expensive in-house corporate legal teams – and you’d be hard-pressed to find one without some external firms on retainer. In fact the modern generation of powerhouse legal firms of today (think Suits) only emerged after Jack Welch started the in-house revolution by hiring a heavy-hitting legal team at GE in the 1980s.

Both, unsurprisingly, beats one or the other.

The Age of the Sophisticated Buyer?

From our perspective as an external partner, it’s easier for us to facilitate step changes if there’s a great in-house product team in place: we can get closer to the product faster, and can gain enormously from the experience that team has working within its organisation on a daily basis. Those insights can spark all sorts of new ideas in our team and we can short-cut all sorts of dead-ends without losing the value of our role – to bring a broader perspective and a different mindset to bear on the same challenges. We do our best work alongside great in-house teams, because they only get to be great when they realise that we each have a role to play that the other can’t.

Unsurprisingly, the benefits go both ways. We learn something new from each team we work with, and our involvement always leads to an acceleration in the continuous part of the graph too, because even when we work with the most accomplished in-house teams, we’re always able to leave them with some new techniques, new tools to think with, or insights from other sectors that enable them to do their own work better.

Perhaps we’re finally at the point where the more progressive organisations are going to capitalise on the potential presented by an effective internal-external collaboration. Having seen in-house teams bed-in over the last few years, growing in their own knowledge and confidence in turn, organisations are at a point where they can approach digital expertise exactly as so many mature sectors have approached external support before them.

After this period spent building internal capability and getting overall standards up to scratch, I believe we’re heading into an era of greater leaps in the digital products and services we all use again. This will be an era of greater focus on differentiation and, dare I dream it, more confidence in the value of design and its role in commercial success.

]]>http://www.mindtheproduct.com/2016/04/turbocharging-product-development/feed/0http://www.mindtheproduct.com/wp-content/uploads/2016/04/Turbocharge.pngSleepwalkers: Managing Customer Inertiahttp://www.mindtheproduct.com/2016/04/sleepwalkers-managing-customer-inertia/
http://www.mindtheproduct.com/2016/04/sleepwalkers-managing-customer-inertia/#respondTue, 05 Apr 2016 09:28:06 +0000http://www.mindtheproduct.com/?p=8216Don’t look now, but there’s a customer behind you who’s not as she appears. She has Sally’s face and Sally’s credit card, but let me assure you, that is not Sally. Notice the empty eyes and the shuffling gait? She’s a zombie! Just kidding–kind of. Sally is what I call a Sleepwalker and she’s not […]

Don’t look now, but there’s a customer behind you who’s not as she appears. She has Sally’s face and Sally’s credit card, but let me assure you, that is not Sally. Notice the empty eyes and the shuffling gait? She’s a zombie! Just kidding–kind of. Sally is what I call a Sleepwalker and she’s not the only one. Sleepwalkers are customers who only stick around because of inertia. You can transform them into a powerful new customer segment or watch them clog up your product. You may already know of them as ‘Zombie customers’ but, as I’ll explain, I think ‘sleepwalker’ is the more appropriate metaphor. Either way, the adage applies: Be careful when disturbing a Sleepwalker (they may bite!)

What Are Sleepwalkers?

Sleepwalkers were once your biggest fans. They gushed about your product, probed new features and burst Kramer-like into your inbox with bug reports and feedback. Years passed and they dozed off. Your product stayed the same, but your super-fans shifted into auto-pilot. Sleepwalkers drag your product around for comfort, knowing in the back of their head that they should move on but maybe tomorrow. Many product managers look at frequent visitors as a homogenous group and treat them all as core customers. Don’t make that mistake!

Why Sleepwalkers Stick Around

You drive the same route to work every morning. When you first got the job, you scrutinized every turn. After a few weeks your drive became foggy. Now, you teleport trance-like from point A to point B, because your commute is hard-wired into your brain. Nothing less than major construction will change your route.

Like your commute, visiting websites or opening apps is habit-forming. Sign in often enough, for long enough, and good luck quitting. Every morning I visit the same dozen websites. One is about travel deals, an artefact of a long trip I planned six years ago. I haven’t purchased a deal since, but I’ll still reflexively type the URL. One day I’m going to re-evaluate my web browsing habits and maybe block the travel deals site. Maybe tomorrow.

Sleepwalkers have your product hard-wired into their brains. They’ll keep visiting, uninterested, until disrupted. Sleepwalkers aren’t the same as Lurkers, though. While Lurkers don’t participate, they still care, and Sleepwalkers are long past the point of caring.

Case Study: Website Acquisition Gone Wrong

My company once acquired a website with a 10-year history. We were excited because Google Analytics promised massive frequent visitors. The previous owner hadn’t significantly updated the website in years, so we thought it was ripe for a resurgence. After the acquisition, disaster.

The frequent visitors couldn’t be bothered. I’d post an announcement and no clicks. I’d create a new feature and no takers. I’d ask for feedback to help build a new version and silence. Yet those visitors, with confirmed accounts, still logged in every day. After months of gentle tweaks and aggressive courting, I realized that we were dealing with something different. Sleepwalkers.

We unloaded the website to another company. This company relaunched it with a beautiful new design and all the Sleepwalkers woke up and walked away. Their hardwiring was short-circuited.

How Do You Measure Sleepwalkers?

Sleepwalkers are inevitable. They roam around all products. Their number is proportional to how long your product has been around, since habits take time to form. Sleepwalkers crowd products that don’t change often, because change breaks their slumber. If your product is old and looks the same as it did 10 years ago, you’re infested.

How do you measure Sleepwalkers scientifically? Filter your frequent visitors by whichever engagement statistics matter to you and chart that over time. For example, if a year ago 10% of your frequent visitors bounced and today 20% bounce, the extra 10% are Sleepwalkers. Ditto if your average pages per frequent visitor is on the decline or if you notice a large swath of frequent visitors who never add anything to their shopping cart.

Surveys are another method of assessing Sleepwalkers, although you have to be aggressive. Call frequent visitors directly or incentivize them with treasure. Ask what their primary purposes are for visiting and make one option “Habit.”

Are Sleepwalkers Good or Bad?

Sleepwalkers are a mixed bag. If you rely on advertising or investment, Sleepwalkers boost your audience numbers and make you look popular to stakeholders. Equally, if you work hard and have finesse, you can restore Sleepwalkers to their former glory. That’s the dream.

On the other hand…

Sleepwalkers take up space. A newsletter with a lot of Sleepwalkers will drive down open and click through rates and cost more money to send. If your product is consumer-facing with public usernames, many of your best names be owned by Sleepwalkers instead of stars (see @realdonaldtrump).

Sleepwalkers can futz up your projections. Say you’re developing a feature and wager that 10% of your core customers will buy it. You’ll lose that bet if half of your core are Sleepwalkers.

Sleepwalkers are driven away by disruption events. If you relaunch and shoo away thousands of Sleepwalkers, your stakeholders won’t accept any explanation.

Sleepwalkers can make you too conservative. Instead of catering to a smaller group of passionate fans, you’ll have to manage a bloated mix.

How Do You Manage Sleepwalkers?

Ask yourself if re-engagement is worth the bandwidth. If you’d rather stay lean then be aggressive with changes, focus on user behavior from passionate fans and force people to re-opt into your service from time-to-time.

The Alarm Clock Approach

Here’s a thought experiment. What would happen if you sent your email list a “Yes, I still want to receive this newsletter” message? Few marketers on Earth would approve losing 80% of their subscribers overnight (and for some newsletters, maybe 99.8%), but imagine the fun you could have with a pared down list of power users.

You could call every single subscriber. You could send better-than-average offers to this better-than-average group. You could find interesting new segments. You could wow advertisers with amazing response rates and take more risks with content.

Culling Sleepwalkers isn’t for the faint of heart, though. If you’d rather fight and win them over, here are a few tips.

Tips for Gently Waking

Go slow and steady. Make changes that entice them, but don’t go overboard and all-at-once with those changes. Digg, Netscape, Yahoo! Mail and many others made that mistake, and Sleepwalkers would rather leave than learn a new UX.

Downtime is anathema to Sleepwalkers. I’ve seen a product permanently lose 10% of its daily audience because of a single day’s screw-up. Over-invest in redundancy.

Sleepwalkers respond well to novelty. If you pass by a flashmob during your morning commute, you’ll take notice, even if you don’t change your route. Sleepwalkers like flashmobs too, so have fun with your product. Change your logo for the season, sponsor a silly contest or host a head-turning event. Use this new-found attention to direct Sleepwalkers to deeper parts of your product. Sleepwalkers probably have no idea your product launched a killer feature six months ago. Maybe they’ll fall in love with that killer feature and re-engage.

Experiment with adjacent products. It’s often easier to make something new for Sleepwalkers than it is to change your product enough to win them over. I’ll never buy another travel deal, but if that travel deals site held an easy contest that introduced me to a travel photography app, I might bite.

Maintaining your product’s quality is critical. Don’t get complacent. Of course you’ll have Sleepwalkers accessing your product, but do you know what ratio of your customers are only returning because of inertia? If the moment comes when a Sleepwalker re-evaluates his or her behaviour — maybe after a long vacation — you want to remain the best option. The worst kind of Sleepwalk is the one who now sleeps with your competitor!

]]>http://www.mindtheproduct.com/2016/04/sleepwalkers-managing-customer-inertia/feed/0http://www.mindtheproduct.com/wp-content/uploads/2016/03/Alex-Bamford-_BAM4477.jpgEmbracing new ideas in user-centric agile developmenthttp://www.mindtheproduct.com/2016/02/embracing-new-ideas-in-user-centric-agile-development/
http://www.mindtheproduct.com/2016/02/embracing-new-ideas-in-user-centric-agile-development/#commentsThu, 25 Feb 2016 09:52:48 +0000http://www.mindtheproduct.com/?p=7869We’ve all been there. You are working on a product, your team and clients get excited about it and start sharing an early build with friends and investors. Before you know it, a number of new features and ideas about what the product should or could do are on the table. These ideas are often […]

We’ve all been there. You are working on a product, your team and clients get excited about it and start sharing an early build with friends and investors. Before you know it, a number of new features and ideas about what the product should or could do are on the table. These ideas are often informal opinions of people we trust but, as they are not the result of user-testing, agile teams often lack a structure to filter, refine and incorporate them into the product.

As a result, many of these points are either ignored, or vilified as one of the Product Manager’s worst nightmare: ‘feature creep’. This is a missed opportunity, and one that could easily be resolved by looking at the Workflow and working out a way to incorporate the ‘new’ without derailing the product development process. And here is how.

Riding the Brainwave

As product managers, we love to optimise the way we build products. In fact, happiness often takes the form of an idea that not only improves workflow for your team, but also benefits the Product Owner and ultimately (not to mention most importantly), the user.

When you follow a user-centric approach to building a product, you are creating something from your customers’ and business’ perspective. The features of the product emerge from validated user needs (or user stories) that make their way to your backlog. Once there, items get prioritised and added into a sprint, and you will iteratively build your product from there. So far, so good.

However, this workflow has a flaw that I think a lot of Product Managers who have embraced Agile and Lean will have experienced. Especially us PM’s that come from a user-centric philosophy or from a design background. Specifically, it can allow very little room for new ideas and assumptions to influence the development. Because we are moving so quickly and everything is already prioritised, to fit something NEW in gives you a bit of a headache.

But what if you get a brainwave for an improvement or a slight pivot to the product’s direction? Following a user-centric approach, these items in your mind are not validated user needs, so how can they make their way into your Agile workflow?

In my experience, the solution is quite simple – you need to allow room for completely fresh ideas and assumptions within your sprint cycle. How? It’s pretty simple. You basically add in an element of testing to validate these ideas within the sprint.

Incorporating a “Gitflow”

To develop our approach at Hive we borrowed concepts from an engineering concept called Gitflow. Originally created by Vincent Driessen at nvie, this is a process that facilitates collaboration, parallel development and allows for the handing off of priorities.

We found it helpful because it nicely illustrates the process of handing off priorities along a timeline and merging outcomes. It also didn’t hurt that the team already understood the ideas behind it.

Two buckets of items:

To add new ideas into your agile workflow, you need to have two buckets of items. One bucket contains your ideas and assumptions,The other bucket works the same as you would with any product backlog: you estimate the effort of the items, you prioritise based on the importance for the user and the business, and you start from the top of the pile.

The next step is to take an item or items from your assumptions bucket and create tests around it to run in your current or upcoming sprint.

Real World Example from Kindeo

The easiest way to explain this is with an example. We are currently working with Kindeo, a product that helps bring families together by sharing memories. In the middle of the sprint, we had a brainwave – if our secondary users (that is not the users that would generate the stories, but those who would view them) invited their parents or grandparents to share their stories, then the product would become a more personal and inviting experience.

As a team we discussed how we could validate this new assumption. We decide that the best test would be to add “invite someone” functionality to the landing page, track its usage, and get feedback on the experience. After a week, we had some results and concluded that this was a feature to develop in in the next sprint.

In short, it is all about “hacking” together a test for the your assumption as quickly as possible, validate it as a genuine user need, and then working on it (or not!) in a future sprint.

Using the Gitflow to manage two workflows

As I mentioned earlier, I believe that incorporating this into your agile workflow is easiest done in a Gitflow model, treating the idea validation process as a complimentary workflow. Your new Gitflow will have a new Branch to consider, but ultimately works on the same principles. What we have created is a second, complimentary workflow within the same sprint, as explained in the image below. As a Product Manager, you can treat the new workflow the same as any agile development sprint – take items from a backlog, estimate, execute and learn.

Once you have established a good workflow and your product owner has bought into this, you has a Product Manager (perhaps collaborating with a project manager) now have to manage two separate workflows within your sprint. Obviously, you won’t have the same kind of user stories you’re probably familiar with, but there are ways of sizing these pieces of work and smoothly incorporating them in the team’s planning.

In this process, it is important to timebox the testing and agree on a metric of success for it, for example “We will agree this idea or assumption is a validated need when X=Y”. Agreeing those kinds of success metrics are naturally a challenge, but a valuable one to wrestle with, essential if you want to be able to effectively test new ideas. This will obviously also have an impact on your product development cycle, but it will also frame learning and idea validation in a way that is accessible to everyone in the team.

The Benefits

As a Product Manager, incorporating and managing new ideas within your workflow in an efficient way is very powerful. Here are some of the clear benefits:

1.Everyone understands what it takes

As the whole team has been involved in the testing of the idea and understands both the benefits and the complexity of the new feature, it will be easier for them to estimate the effort of building it.

2.You avoid unnecessary features

As the Product Owner has been involved both in the idea process and the testing, it’s easy to discuss and assess the importance of each new feature. What’s more, you will have not only your own experience to fall back on, but real user data to help in the discussions as to whether a feature should be built or not. It is not about guessing the value of random new ideas, but about listening to what the users are saying when presented with new ideas.

3. The user “rules”

This is an inclusive approach where everyone is part of the the design and the development process – the team, product owner, and even investors. All ideas have the opportunity to be tested with your customers, and the users are the final judges as to whether this is something they want or not.

To Summarise

Overall, this is an approach that gives products the best chance to succeed, introducing the flexibility needed to learn and validate ideas as they arise without derailing your sprint.

Hypothesize, validate, build, iterate and repeat for better products! If you have any comments or other ideas in how to include new ideas in your workflow I would love to hear them.

]]>http://www.mindtheproduct.com/2016/02/embracing-new-ideas-in-user-centric-agile-development/feed/2http://www.mindtheproduct.com/wp-content/uploads/2016/02/Seb_Illu_01-04.pngWhen Customer Feedback Leads, Positive Metrics Followhttp://www.mindtheproduct.com/2016/02/when-customer-feedback-leads-positive-metrics-follow/
http://www.mindtheproduct.com/2016/02/when-customer-feedback-leads-positive-metrics-follow/#respondTue, 23 Feb 2016 10:00:04 +0000http://www.mindtheproduct.com/?p=7846It’s an inarguable fact: Metrics are useful. But they’re missing something—they don’t tell you the whole story. Quantitative metrics can tell you that a problem exists, but they can’t tell you what exactly the problem is or why it exists. Product managers are often tasked with increasing KPIs on their products, but they can’t do […]

It’s an inarguable fact: Metrics are useful. But they’re missing something—they don’t tell you the whole story. Quantitative metrics can tell you that a problem exists, but they can’t tell you what exactly the problem is or why it exists. Product managers are often tasked with increasing KPIs on their products, but they can’t do that by simply analyzing numeric data on its own.

To uncover the full story, it’s up to product managers to gather and interpret customer feedback and reveal what the metrics can’t—why the KPIs are changing (or not). In other words, you have to gather qualitative data.

Peel Back the Layers of Customer Feedback

Customer feedback has several layers. As I’ve learned over time in talking to customers, it’s often not about what people say, but rather what they don’t say. For example, when customers are struggling to accomplish their goals in your product, they will often come to you with specific solutions as how to solve the problem. It would be easy to take that one piece of feedback, add it to the roadmap and implement it directly as described. But it’s important to understand that people’s solutions are often based on their own personal preference or point of view, and that may not align with your entire customer base.

If you implement only one new tactic this year, make it this: Get out of the office and observe your customers using your product. That is the only way you will truly be able to figure out the true nature of your customers’ problems, why they exist, and how to solve them. Schedule an interview or user test with a new customer once a week (or at least every two to three weeks), and dig deep into the issues you discovered while reviewing your metrics.

It’s in these user tests that you are able to see problems occur in their natural environment. Your customers will show you their workarounds. They will tell you stories about how they “make do” using other products. You will observe their frustration as they try to do something your product doesn’t allow, or as they get confused about what to do next.

Proving That the Problem is Real

Since customers tend to start out by telling you the solutions they want, getting to the bottom of the problem is not always as straightforward as we’d like. Thankfully, there are three rules that can help you navigate the conversation to get you the answers you need.

1. Look to Answer the Four W’s

In this case, the four W’s we are referring to are Who, What, Where and Why.

Who has the problem? Which customer group are you really focused on? Most products have more than one persona. Thus, it’s important that you understand which persona you’re speaking to.

What is the nature of the problem? You want to get to the point where you can explain the problem simply, preferably in one to two sentences. Additionally, you need to be able to communicate to your team how you know that this particular customer is experiencing this particular problem. So, ask your customer to walk through the product and make note of where they get stuck.

Where does the problem arise, or in what context do your customers experience the problem? When you work to come up with a solution, you’ll want to make sure you do so in the areas your customers are most negatively affected.

Why is the problem worth solving? Is this problem affecting a large portion of your customer base? And if so, what does the problem mean for your brand, revenue and trust in your product.

2. Avoid Asking Leading Questions

Leading questions will get you the answers you want, but may not get you the answers you need. They are questions that tell the listener the answer you want them to give you.

Generally speaking, there are two ways to spot leading questions. The first indication is that the question can be answered with a yes or no. These closed questions seem pretty harmless, but they tend to be asked with a tone that puts emphasis on either the ‘yes’ or the ‘no’, thereby giving the listener the indication as to which you want them to say. The second indicator of leading questions is that they tend to have a solution in the question, e.g. “Would you use product X more if it had feature Y?”

3. Seek to Disprove Your Assumptions

When building products, we make assumptions regarding what we believe to be true about our product and our customers. It’s appealing to try and confirm that we’re right, but when going out and talking to customers, you’ll actually get to the bottom of problems (whether or not they are real and worth solving) much more easily if you try to prove yourself wrong. Ultimately, this will help you avoid trying to solve the wrong, or less important, problems.

In your interviews, the first step is to avoid bias in your questions. Particularly Confirmation Bias, which happens when you (possibly unconsciously) interpret what your customer says and does in a way that confirms your preconceptions. This also shows up when you only ask questions based on what you expect to see. Additionally, you should watch out for Diagnosis Bias, which is when you form an initial impression and are then not open to other possibilities, either based on your initial assumptions or based on something that happens early on in the user test.

Secondly, ask questions to get an opposite answer than what you think to be true. So, if you believe a feature is good, ask your question in a way that will help you to determine how it could be bad. “If feature X fails, what are your workarounds?”

Back to the Beginning—Turning Feedback Into Metrics

As I said in the beginning, quantitative metrics can tell you that there is a problem, but they won’t tell you what that problem is or why it exists; qualitative data is how we get real understanding. But when it comes to measuring whether or not we truly solved the problem we set out to solve, it’s important that we bring it back to numbers. So as you decide on product changes based on what you learned, ensure that those changes are measurable by the KPIs you set out to change.

As your customers experience your solution, your metrics will adjust to reflect the impact of your changes. If you’ve made changes that truly solve the problem, you’ll see a positive impact in your metrics. If you missed the mark, as sometimes happens, your numbers will show that too. Either way, this step is really just taking you back to the beginning, as this is an ongoing feedback loop.

As product managers, we need to constantly evaluate our product and repeat this cycle over and over: Review metrics to discover where to focus our time, talk to customers to understand the true nature of their problems, and then measure whether or not our changes had a positive or negative impact (and by how much).

Metrics are the beginning and end of the story. They indicate to you that you need to change something, and they tell you when you can move your focus to something else. But in the middle, getting quality customer feedback is essential to making decisions that will move your metrics in the direction that will positively impact your customers and business. More importantly, those conversations lead to solid understanding of your customer. And understanding your customer and their needs is what leads to increased metrics all-around, no matter what conversion metric you measure.

So while metrics are incredibly important, don’t forget that you have humans using your product. In the words of Harvard Professor Youngme Moon, “If we pay attention to things that we can measure, we will only pay attention to the things that are easily measureable. And in the process we will miss a lot.” We miss the human experience.

]]>http://www.mindtheproduct.com/2016/02/when-customer-feedback-leads-positive-metrics-follow/feed/0http://www.mindtheproduct.com/wp-content/uploads/2016/02/Customer-Feedback.jpgFrom Waterfall to Agile: A Product Manager Transitionhttp://www.mindtheproduct.com/2016/02/waterfall-agile-product-manager-transition/
http://www.mindtheproduct.com/2016/02/waterfall-agile-product-manager-transition/#commentsTue, 16 Feb 2016 08:22:16 +0000http://www.mindtheproduct.com/?p=7438A few weeks back, Martin Eriksson reviewed the history of Product Management and explained how the discipline was born in the FMCG manufacturing industry. At the time, the process for creating products was similar to the Waterfall project management model we’re familiar with because the development, testing, production and market distribution of physical goods is expensive and […]

A few weeks back, Martin Eriksson reviewed the history of Product Management and explained how the discipline was born in the FMCG manufacturing industry. At the time, the process for creating products was similar to the Waterfall project management model we’re familiar with because the development, testing, production and market distribution of physical goods is expensive and slow. Everything has (or at least had) to be planned and spec-ed out in detail in an attempt to prevent mistakes and costly changes later in the process.

Software Development and Waterfall

This same Waterfall model was later adopted for software product development as a familiar working model. The process made sense in a world where getting users to test and validate your product and delivering updates where both hard and expensive activities. Hence a lot of emphasis was put on spec-ing out every detail of the product, planning development and ensuring the quality of the product before release. Multi-year release cycles weren’t uncommon.

In Waterfall, the Product Managers initially spends most of their time doing market research and talking to the different stakeholders to capture the requirements. They document those requirements in a long, detailed product specification document that is handed over to the development team for implementation. Then, during the implementation phase the Product Manager has time to work out the details of the go-to-market strategy: marketing message, pricing, distribution channels, etc.

Agile Becomes Popular

In the late 90s, the growth of the Internet unlocked a new way to deliver software: Application Service Providers (ASP), which ultimately evolved to Software as a Service (SaaS) a few years later. This new delivery channel changed completely the landscape: updates to the product could be delivered rapidly, and user feedback captured immediately. This allowed for a much more efficient way to build software that would quickly adapt to market needs.

The introduction of these new project management principles has had a very important impact in the role of Product Management. While the goals remain the same, the way to achieve those goals has evolved significantly and organizations have been working hard to figure out how to organize the Product Management function to ensure the success of the products they build.

My Experience Adopting Agile

I have spent the last five years doing product management for an enterprise software application. When I joined back in 2011 we started the transition from Waterfall to Agile by borrowing some concepts from SCRUM, like the sprints and the Product Owner role. While you may be surprised that we were still using a Waterfall process not that long ago, keep in mind that, because of security concerns, many IT organizations in the enterprise world only started to accept storing their data outside the confines of their firewall 3-4 years ago. On top of that, they were unwilling to install, test and validate new releases often (as that was perceived as expensive), so we didn’t have such a big incentive to move to Agile!

In our own journey from Waterfall to Agile, our Product Management function has evolved through three different configurations. Below, I share my experience of the pros and cons and the impact in the product development process of each of them. It is also worth mentioning that the size of the company increased fourfold in the same period of time and, while we have some teams that work in an office, most of us work remotely from each other.

1. The Super Product Manager

I was the first Product Manager to join the company. Initially my role consisted mainly of the following tasks:

Talking to customers about problems and features.

Managing the Product Roadmap.

Writing specifications.

Occasionally supporting engineering during the development in case there were questions.

It was a very broad and challenging role with many responsibilities, and it was difficult to do everything well.

The Cons

With the change towards an Agile methodology, the Product Management responsibilities initially grew even further to cater for the required involvement in the development process. In particular, there was a continuous cycle of prioritizing the backlog, selecting what to do in the next sprint, writing user stories, clarifying requirements during development, etc., which all consumed a lot of my time. At some point I was even very involved in scheduling and tracking engineering work.

So basically, I found myself being tasked with even more things to manage than I had before!

The Pros

The change in the process brought some positive outcomes too. I was now spending more time with the engineering team, which helped us build more alignment – a common understanding of the product we were building and why we were building it. The new process also allowed us to adapt faster to new requirements and new market needs, which made us more competitive and fueled our growth. We released a new version every month while the competition was by and large still releasing a new version of their products only every 12 to 18 months.

The Verdict

In my experience, this configuration works fine for startups or small teams. however, at our scale, it soon became clear it was too much for a single person to do. Something had to give and this is how we decided to split responsibilities between a market-facing Product Manager and a team-facing Product Owner.

2. The Odd Couple: Product Manager and Product Owner

We looked for advice from industry experts on agile practices to see how they had resolved our “Super Product Manager” problem. This led us to discover the Scaled Agile Framework Extension (SAFe) which distinguishes between the role of Product Manager and Product Owner. Using SaFE as an inspiration, we divided the roles in the following way:

Product Manager (PM)

Product Owner (PO)

Market / customer facing

Product team facing

Owns vision, roadmap, go-to-market

Owns release plans, product quality

Provides prioritized high level feature backlog to the Product Owner

Provides prioritized user story backlog to the product team

Defines feature acceptance criteria

Defines user story acceptance tests

The Pros

This configuration allows the PM to spend most of their time in the market, defining the product and market strategy. It delegates the more tactical work to the Product Owner, who is also the one that represents product management and the user in front of the product development team.

For this configuration we selected a more business-oriented person for the PM role, and more technical-oriented person for the PO role.

The Cons

We soon realized this set up had two main drawbacks: conflicts in priorities, and lack of team alignment with the product strategy.

The conflicts in priorities arose because there wasn’t a single owner of the backlog, and the PM and the PO weren’t in perfect alignment in terms of strategy. What happened is that while the high level features (or “epics”) were prioritized based on business value, the more tactical work that was added to the backlog by the team wasn’t because the PO didn’t interact directly with the market. This included things like smaller improvements to existing features, which in some cases weren’t the top priority for our customers even if they made logical sense.

The lack of alignment between the PM and the PO, and the indirect communication between the PM and the product team also led to a disconnect in the vision and understanding of the real business value of the features being implemented. Moreover, it created confusion inside the organization because there wasn’t a single “owner” of the product. Depending on the type of issue, questions or requests would need to be addressed to the PM or the PO, which led to even more misunderstandings and even less alignment in the priorities.

The Verdict

Given those problems, exacerbated by the remote work set up, we ended up giving all the prioritization responsibilities to one single person and transitioning to the configuration we are using today…

3. The Dynamic Duo: Product Manager and Product Marketing Manager

When we decided to merge the Product Manager and Product Owner roles back into one single person we obviously couldn’t go back to step 1, and so we still had to hand over some of the responsibilities. We decided to introduce the Product Marketing Manager role:

Product Manager (PM)

Product Marketing Manager (PMM)

Brings market knowledge to the product

Brings the product to the market

Owns product strategy

Owns go-to-market strategy

Defines requirements

Develops sales tools

Manages backlog priorities and the release plan

Manages the product launch plan

The Pros

This configuration has allowed us to centralize the ownership of priorities in the PM, and also give that person time to talk to the product team to sell the vision and business value of the different features being built. This translates overall into a better understanding of the market and the users by the product team. We have also found that alignment between the PM and the PMM has been much easier to achieve. I suspect this is because of two reasons.

First, the alignment only needs to be reached at the vision and roadmap level, which doesn’t require as much frequent communication as the more tactical daily work inside the development team. The two usually only need a one hour call per week to stay on the same page. And second, both speak the same business language and rely on very similar market information to make decisions. Actually, they both often share market and user research information.

As an added benefit, this configuration has proven well-suited to supporting our move to a Design Thinking approach to finding problems and discovering the best solutions. The PM can now easily bring together users and team members to collaborate to build better products.

The Cons

We haven’t encountered any major drawbacks thus far, but I can see problems arising if the separation of duties between Product Marketing and Product Management aren’t clearly defined, or if there is strong disagreement on the product strategy defined by the PM. In that scenario, the PMM may be messaging the product to a market that it is not designed to serve well.

The Verdict… so far

This is were we are in our journey. I am sure we will refine the current Product Management configuration as we learn and discover ways to improve the way we build products.

What Product Management configuration are you using currently? What is working, not working for you? Let’s start a conversation in the comments.

]]>http://www.mindtheproduct.com/2016/02/waterfall-agile-product-manager-transition/feed/7http://www.mindtheproduct.com/wp-content/uploads/2015/11/Agile-juggling.jpgThe Product Managers’ Guide to Continuous Delivery and DevOpshttp://www.mindtheproduct.com/2016/02/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/
http://www.mindtheproduct.com/2016/02/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/#commentsThu, 11 Feb 2016 09:57:01 +0000http://www.mindtheproduct.com/?p=7496This guide is for you if …. You’re in tech, you’re a product manager or an MBA. Your team A/B tests, feature toggles, and you have a dog in the office! Of course you understand what feature branches are, what CD is and what a DevOps culture looks like. Right? Uh … sure. You’ve gone […]

You’re in tech, you’re a product manager or an MBA. Your team A/B tests, feature toggles, and you have a dog in the office! Of course you understand what feature branches are, what CD is and what a DevOps culture looks like. Right? Uh … sure.

You’ve gone Agile. Engineering teams now meet with your product people every week to discuss stories and iterations. They collaborate well and what they’re building feels better than ever. But your customers still don’t get those features any faster. You still have to wait for the release train to leave the station. You’ve heard about companies like Etsy, Flickr and Google who deliver a 100 times a day. How do they do it?

Your development team wants to “do CD”. You’ve heard some good things but you’re also concerned about changes going to production without them being properly tested or not being able to market the changes properly. What is this CD thing?

I am here to demystify these practices, tell you just how important they are to you “on the business side” and help you get involved. It’s not that complicated, we have pictures and everything.

Let’s start with some definitions and examples

Continuous Integration (CI)

In traditional software development the process of integration generally took place at the end of a project after each person had completed their work. Integration generally took weeks or months and could be very painful. Continuous integration is a practice that puts the integration phase earlier in the development cycle so that building, testing and integrating code happens on a more regular basis.

CI means that one developer (hi Steve!) who writes code on his laptop at home, and another dev (hey Annie!) who codes on her desktop in the office can both write software for the same product separately, integrate their changes together in a place called the source repository. They can then build the combined software from the bits they each wrote and test that it works the way they expect.

Developers generally use a tool called the CI Server to do the building and the integration for them. CI requires that Steve and Annie have self-testing code. This is code that tests itself to ensure that it is working as expected, and these tests are often called unit tests. When all the unit tests pass after the code is integrated Steve and Annie will get a green build. This indicates that they have verified that their changes are successfully integrated together, and the code is working as expected by the tests.However, while the integrated code is successfully working together, it not yet ready for production because it has not been tested and verified as working in production-like environments. You can read more about what happens after CI in the Continuous Delivery section below.

To be considered to be practicing CI, Steve and Annie must check-in to the main source repository, integrate and test their code frequently and often. Usually many times an hour, but at a minimum once a day.

The benefit of CI is that integration becomes a non-event. Software is written and integrated all the time. Before CI, integration happened at the end of the creation process, all at once, and took an unknown amount of time; now with CI, it happens everyday, takes minutes and is just “the way we work”.

It’s most likely the your team is doing CI (or at least they believe they are). You can confirm by asking them whether they integrated code once a day CI is the first practice that is required to do Continuous Delivery. In fact, if you’ve ever checked in help text, documentation or images, then you may have been continuously integrating!

Continuous Delivery (CD)

Let’s go back to our two developers, Steve and Annie. Continuous Delivery means that each time Steve or Annie makes changes to the code, integrates and builds the code, that they also automatically test this code on environments that are very similar to production. We call this progression of deploying to – and testing on – different environments a deployment pipeline. Often the deployment pipeline has a development environment, a test environment, and a staging environment, but these stages vary by the team, product and organisation. For example, our Mingle team has a stage called “Cupcake” which is a staging environment, and Etsy’s staging environment is called “Princess”.

In each different environment, the code that Annie or Steve wrote is tested differently. This gives more and more confidence to them, and to you, that the code will work on the production environment when the code is deployed there. Crucially, the code is only promoted to (tested on) the next environment in the deployment pipeline if it passes the tests of the previous environment. This way Annie and Steve get new feedback from the tests in each environment and, if there is a failure, they can understand more easily where the issue might be and get it fixed before the code gets to the production environment.

Continuously Learning

This process is very empowering for those of us in the business. It means that if Annie’s tests pass on all the environments, you know that her code is likely to be work as intended when it gets to production. Once the tests pass in all environments, you get to decide whether your end users get it or not, right away. Do we want this green build in production now? Yes! And with that, new, fully tested, working software is readily available for customers as soon as your developers finished building it. Woot!

Continuous Deployment

This is a practice where every change that Steve or Annie makes, and which passes all the test stages, automatically goes to production. Tim Fitz has a great explanation of it as it was first coined. Some companies do this and others do not. To achieve continuous deployment you first need to get to continuous delivery, so it’s not a priority to decide which is better for you until you’ve starting practicing CD. Either way, I’m of the opinion that continuous delivery is about empowering the business as a whole, and so at the very least you should be involved in deciding if you should use continuous deployment or not. After all, if you’re reading this then you’re probably on the “business side”.

DevOps

The word ‘DevOps’ comes from the combination of the words ‘development’ and ‘operations’. DevOps is a culture that promotes collaboration between developers (hey Steve and Annie, you’re back) and other technology professionals, often called operations or just ops (high-five ops star Joey!). Specifically, communication and collaboration during the software delivery and deployment process, with the goal of releasing better quality software more quickly and more reliably.

Common traits of organisations who have a so-called DevOps culture are: autonomous poly-skilled teams (Steve, Annie and Joey are all on the same team), high levels of test and release automation (a la continuous delivery) and common goals between the poly-skilled members.

One way you may see this working in your organisations is that our developer friends Steve and Annie will work with ops people like Joey to deliver software into production, rather than just “hand off” their code to Joey for release when they’re done with it. Likewise Steve, Annie and Joey will all act as part of a common product or service team who will all be responsible for the support and maintenance of the product, rather than support being a solely ops-team responsibility.

You will also see automation of activities becoming increasingly important to an organisation doing CD and DevOps. This is because, in order to achieve the repeatable, regular and successful process of releasing software that we expect from CD and DevOps, organizations must move to an automated process. Manual processes are simply too error prone and inefficient.

DevOps culture is commonly associated with Continuous Delivery because they both aim to increase collaboration between developers and operations teams, and both use automatic processes to build, test and release software more quickly, frequently and reliably. All things that people like us want.

What’s Next?

While development teams often see the most immediate benefits of process improvements, there are lots of benefits of CI, CD and DevOps to the rest of us. Put simply, I believe that organisations practicing CD and embracing a DevOps culture will deliver more valuable, reliable software to their customers, more often. That’s got to be good, right? Especially if you’re on “the business side.”

Next time I will talk more about why you should care about these concepts. I’ll address the impact it can have on your business and how to get involved. If you have any questions, talk to me in the comments. The whole point of these posts is to empower you and inform you about technical practices that are meant to be business-relevant. Questions are great!

Useful Terminology

Checking in

The process of pushing local development code changes to the common source repository.

CI server

A tool used to build and test source code. The CI server will tell a developer if their latest code builds were successful and if they continue to pass tests.

Development environment

Where developers create, integrate, build and test code.

Deployment pipeline / pipeline

This is a set of stages that Steve and Annie’s code changes go through before they are done and ready to be delivered to production. Commonly these will be “build”, “unit test”, “functional tests”, “performance test” and “deploy”. Different automated tests will be run at different stages. Only once the code goes through the entire deployment pipeline can the software be delivered to production.

Green build

Green is an indication of success. A green version or build is one where it has passed the tests for that particular stage of the development and delivery process. Generally a build or version of the software will not be promoted to the next stage of the deployment pipeline unless it is “green”. The opposite of a green build is a red build (see below).

Incremental development

Not to be confused with iterative development (see below). Incremental development is where a little bit of the product gets built at a time until it is all complete. Pieces are added on in each increment, and those increments may be small or large. You can use CI with incremental development but it can be harder to achieve Continuous Delivery or Continuous Deployment with incremental development, as you must wait until all increments are completed to deliver value. A great illustration of the difference between Incremental and Iterative development is Jeff Paton’s Mona Lisa.

Integration

All code that is written by individuals or teams needs to be combined. We call this integration. In continuous integration, we generally mean software from individuals needs to be consolidated on a regular basis. In continuous delivery, we often mean software from different teams is integrated together to create the whole product.

Iterative development

Not to be confused with incremental development (see above). Iterative development is where a little bit of the product gets built at a time and is refined until it is complete. The product is built iteratively where the same pieces are reworked each iteration. Change is expected and planned between features in different iterations. You can use CI, Continuous Delivery or Continuous Deployment with iterative development. A great illustration of the difference between incremental and iterative development is Jeff Paton’s Mona Lisa.

Master/trunk/mainline

The “master”, “trunk” or “mainline” branch is the main branch of the source repository. Most people do trunk-based development,meaning that they will always integrate their changes to main line. Others do branch-based development when individually developers will have their own branches, or teams will have branches for different features.

Production environment

This is the place where software gets deployed or released. Customers using your product or website are most likely using this environment. Also referred to as “in production”, “in prod” or “live”.

Red build

Red is an indication of failure. A red version or build is one where it has not passed the tests for that particular stage of the development and delivery process. Generally a build or version of the software will not be promoted to the next stage of the deployment pipeline if it is “red”. The opposite of a red build is a green build (see above).

Source repository

This is where the source code lives. Steve and Annie have their own local version of the code that they are working on (meaning on their own machines), but the source repository will contain all the code after developers check in their changes to it.

Test automation

High quality test automation is needed to do continuous integration and continuous delivery. Tests are ways to check that the software will work as expected. Automated tests are tests that are coded and automatically run once code is checked into the common source repositories.

In the CI world, the unit tests are run each time the software gets integrated and built. If the tests don’t pass, that version of your software is determined as “not working”, “red” or “broken”. In some workplaces “red lights” or sad sounds occur when this happens.

In the case of a broken build, Steve or Annie (whoever committed the malfunctioning code) need to “fix it”, “make it green” or “get it working”. They can either do this by making a change to the code to fix it, or removing the prior change that broke it.

Unit tests

Unit tests are automated tests in code that test low-level, single pieces of code to ensure that they are usable and working as expected. Unit tests are considered a prerequisite for practicing CI and CD.

]]>http://www.mindtheproduct.com/2016/02/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/feed/12http://www.mindtheproduct.com/wp-content/uploads/2015/12/409-images-for-snap-blog-post_image1.pngTransformers: Understanding Product Leadershiphttp://www.mindtheproduct.com/2016/02/transformers-understanding-product-leadership/
http://www.mindtheproduct.com/2016/02/transformers-understanding-product-leadership/#commentsTue, 09 Feb 2016 10:05:23 +0000http://www.mindtheproduct.com/?p=7820We are confused and speechless (in the literal sense) when it comes to leadership. Or shall I say management? After all, we generally call ourselves “product managers”, not “product leaders”. Maybe “product directors”? Or “product owners” who need to lead laterally, as they don’t really have the power to call the shots (contrary to those […]

We are confused and speechless (in the literal sense) when it comes to leadership. Or shall I say management? After all, we generally call ourselves “product managers”, not “product leaders”. Maybe “product directors”? Or “product owners” who need to lead laterally, as they don’t really have the power to call the shots (contrary to those pesky senior managers). I am now called a “Chief Product Officer” – an executive – and I used to be a “managing director” at my previous company. Another three different terms!

How to make sense of this? I propose to describe all those (product) managers (directors, leaders, executives, officers) as transformers!

Let me explain: We are generally unclear about what “product management” and “product leadership” mean, and what it takes to be a good product leader or manager. “Transformer” is an umbrella concept which provides a framework for the various aspects of product management and leadership. Quite literally, transformers create or form something new out of something given. In an organizational context, they are hired to transform the input from resources and people into something meaningful for the organization’s customers. Transformers are the people who take responsibility for getting results, and a product manager takes responsibility for solving the problems of his company’s customers.

This transformational definition of managers (directors, leaders, executives, officers) implies that transformers have certain qualities; they

Choose an attitude of initiative. They do not see themselves as a victims, where external circumstances shape their destiny. On the contrary, they want to shape the future and even risk making mistakes. As a product manager, they do not complain about what’s not working, but instead take steps to make progress.

Understand the context they are operating in, and the results that are expected. As a senior executive of a company, I make sure customers appreciate our products and services, such that our company stays in business. As a product manager, you know what specific problems you are working on and how they relate to the products and services of your company.

Have a bias towards making progress. This includes execution and decisions as well as reflection and insight. As a product manager, you judge each day by the amount of insight you’ve gained and the value you delivered towards your customers.

Now, what do transformers actually do all day? How do they get their results? As the various names suggest, transformers do their job through three functions: directing, managing, and leading.

The Functions of Transformation

Transformers principally fulfil all three functions to some degree, though the respective weightings might differ given the context and personality of a transformer. A product manager focuses more on managing, a product director puts more emphasis on leading (and directing), while a chief product officer has to excel at directing (and leading).

Directing is about meaning – It creates clarity of intent

Directing is a conceptual task. As the name suggests, it is about defining a direction that provides context and purpose. It explains the intent and focuses on the WHY and WHAT, not the HOW. For product development, this is mostly about product vision, strategy, and high level roadmap.

Transformers ensure that such a direction exists. In order to define it, they make sense of the information at hand and create insights out of it. This is followed by a strategic choice of picking one direction and excluding all other options. This gives people clarity of intent and enables them to act within this frame.

While other people could and should help, especially with sense making, directing is the one task that cannot be delegated.

Managing is about resources – It creates alignment of commitment

Steve Jobs used to present new products with “it just works”. This is exactly what you want from any operation that is managed well. Managing means making the best use of people, time, money, and any other resources, orchestrated together. For product management, in practical terms, this is about handling various stakeholders, prioritizing backlogs, making trade-offs between scope, time, and quality. And, if necessary, doing other people’s job.

This is a daily challenge. Structure and processes (the tools of choice) certainly help, but they are not enough. All people have their own agendas and their perspectives on situations will differ, and therefore so do their priorities. This means that structures and processes can and will be gamed. To efficiently manage resources, an alignment of commitment is necessary. The key to getting people to commit their resources, in particular energy and will, is to create a shared understanding of the context.

Each person acts rational and is right – from their own perspective. Sharing those perspectives within your team or organisation will create a deeper understanding of the situation at hand, letting everybody see the whole picture. Once a shared understanding is created, everybody either agrees on how to make trade-offs or is generally much more willing to commit to your decisions, as everybody is heard and has seen equally valid different perspectives.

Leading is about people – It creates autonomy of units

Transformers cannot save the world alone. You need help. Once you’ve defined the intent (directing) and got aligned commitment (managing), you want everybody to work as independently with as much empowerment and speed as possible on the HOW. People should be able to react to new information, changed situations, and new learnings without asking for guidance at every turn.

Leading puts people, teams and units in a position to perform, i.e. it enables them to use and build on their strengths. This autonomy only comes with responsibility, and it needs the mutual trust that people know what is expected from them (WHAT and WHY), and that they have the competence to solve the HOW.

As a product director, you want your product managers to ‘own’ their product as much as possible. It is your responsibility to ensure that your product managers operate just beyond their comfort zone, but not yet in their panic zone. If a (senior) product manager can define a product vision or a roadmap on their own: great! If a (junior) product manager asks for more freedom than his competence allows: be clear and firm about performance expectations and define jobs accordingly. And, as a product manager, you yourself should only ask for the amount of freedom you are capable of handling.

The Traits of a Transformer

So far, I have defined a manager / leader / executive / … as a transformer, i.e. a person who takes responsibility for results, and creates new value out of existing resources. And I explained that a transformer fulfills three functions: directing, managing, and leading. But how do you do that every day, on a practical level? What does it take in terms of traits to be a transformer?

At the risk of sound cliché, transforming requires your whole personality. You need your heart, your brain, and your gut – in other words: it takes compassion, creativity, and courage.

Compassion

Being not only good, but great at anything means doing it wholeheartedly, and acting with passion. A transformer is determined to take responsibility for results in an organization, even though they cannot control everything. It is a people-driven business, so they engage warmly with other people.

Do you want to do that? As a product manager, do you really love digital products? Do you want to make a little dent in the universe, or at least really want to help your customers? I hope so, because it really is a requirement.

Yet, at the same time, with all your well intended determination, do not take yourself too seriously. Value humor, and don’t let your passion become an ideology. There are other truths to be lived. Scrum is not necessarily better than kanban. Engineers and designers both bring great stuff to the party. And in the long run, we are all dead anyway.

Creativity

Transforming means creating something new, and the act of creation surely needs creativity. I personally define creativity as the capacity to find new possible solutions to problems, where the problem can change based on discovered solutions. In other words, it is an iterative process where you look at a starting hypothesis, generate options by letting associations run freely, recognize patterns, and then identify what really matters. Through this process, you sharpen your focus down to the problem that you truly want to solve. You come up with solutions you haven’t thought about before. Now, the problem and the solution make perfect sense together, and you think: “Of course!” At the risk of sounding nebulous, creativity leads to an integration or synthesis of possibilities on a higher level.

As a product manager, you especially need creativity in two domains:

Really understanding, at a very deep level, the customers’ problem you want to solve…

And in your daily operations, solving trade-offs not through domination (“boss said …” ) nor false compromise (avoiding the intense quest for a better solution), but rather by finding integrative solutions that take the valid points from different perspectives into account. As an example, when two people fight over whether to ship feature A or B first, looking at their implicit assumptions might lead to a different understanding of the real problem to solve. That, in turn, should hopefully bring an agreement over which feature is more important, or even a decision to ship feature C.

Courage

Transforming means changing, and change is tough. A good transformer is present in every moment and pays attention to their “gut feeling” or instincts, which should provide them with an inner compass of sorts. Of course, this is assuming that you have a deep understanding of your market and the situation, – a prerequisite for any transformer!

It takes courage to face the truth of how we really see things: not just externally to the organisation, but especially within ourselves. Being courageous means recognizing and reacting to the tensions we sense within the team, across the organization, and even within ourselves. It also means being strong and tough enough to do what needs to get done in order to create a great product.

As a product manager, have you really understood your customer, the other stakeholders, and your team? Are you really trying hard enough to find the best solution? Are you saying NO with truly good reason? When people look for leadership, they are looking for people who stay true to the situation and themselves. This is the basis for the integrity that every transformer needs.

Take Aways

As a leader, you are paid for transforming resources into results (outcome, success). Nothing else.

Regardless of what you are called (leader, manager, director), as a transformer you always fulfil three functions: directing (i.e. create clarity of intent), managing (align commitment), and leading (enable autonomy of units). Although your particular mix of functions might vary, don’t be misled by your formal title on what you need to get done.

Look for and leverage your personal strengths with regard to compassion, creativity, and courage. Find your own way and style in transforming your product.

]]>http://www.mindtheproduct.com/2016/02/transformers-understanding-product-leadership/feed/2http://www.mindtheproduct.com/wp-content/uploads/2016/02/Optimus-Prime.jpgHow to Stop Common B2B Dysfunctions in the Product Teamhttp://www.mindtheproduct.com/2016/02/stop-common-b2b-dysfunctions-product-team/
http://www.mindtheproduct.com/2016/02/stop-common-b2b-dysfunctions-product-team/#respondThu, 04 Feb 2016 09:04:20 +0000http://www.mindtheproduct.com/?p=7657There are several common dysfunctions plaguing product teams in B2B companies the world over. How can you stop them? Read on for suggestions.

“The product team isn’t allowed to speak to customers unless they’re in a sales meeting.”

“Our sales team will often sell something that doesn’t exist, then make it the product team’s problem to make it happen.”

“Our product backlog is full of priority feature requests that the sales person says the customer needs before they’ll purchase.”

You’re not going crazy – nor are you alone. These are common dysfunctions plaguing product teams in B2B companies the world over.

How do you stop them happening? Read on for some suggestions.

A square peg in a round hole

In B2B companies there is usually some kind of ‘solution selling’ methodology in place. The specifics of each selling technique may vary from case to case, but they broadly tend to be along the lines of:

identify a customer’s pain points;

highlight the implications of the problem for the customer’s business;

present a product solution;

tackle customer objections; and

close the deal.

Not an unreasonable approach, I’m sure you’d agree. But isn’t it a coincidence how often the solution happens to be something the vendor can provide, regardless of the customer’s problem?1 With all that pressure on the sales people to close deals, it must be so tempting for them to go ahead and hammer that square peg into the round hole.

Here’s why: when a sales person identifies a plausible opportunity with a customer, they’re typically expected to forecast the deal. This prompts them to look ahead to the commission that they’d gain from the deal.

In their minds, that commission is already theirs for the taking. Loss aversion means they push even harder to close the deal and secure the commission. Details such as the practicality and suitability of the solution for the customer – and feasibility for the vendor – can be left by the wayside.

This is one of the reasons why product teams so often find themselves chucking their carefully researched roadmap out of the window in favour of a creating a product for a target market of one customer.

Two different conversations

A common misunderstanding is that product teams can learn about customer needs during a sales meeting. Simply put: they can’t.

A commercial negotiation is a game between the sales person and the customer. Both sides know they’re in the game, and each plays their cards close to their chest.

The sales person is trying to find the right combination of words, assurances, product and services that will convince the customer to sign on the dotted line.

The customer is typically seeking evidence that the product will deliver on the sales person’s promises (or an assurance it will be rectified if it doesn’t), is trying to negotiate the best value deal for their money and is perhaps hoping that the purchase will make them look good.

In a commercial negotiation, both sides play their cards close to their chests. Or attempt to eat them.(Credit: WikiHow / WikiVisual CC BY-NC-SA 3.0)

This poker game is by definition adversarial – and frankly neither the right time nor place for a customer development discussion.

If you’re attempting to understand market problems and validate possible solutions, you shouldn’t be pitching anything. Instead you want your customer to open up about their working practices and problems.

With a sales person in the room, the customer will be less likely to open up. To reveal the extent of their problems would concede the sales person an advantage in the negotiation (greater customer need = charge more).

Besides, a product manager typically needs to speak with users in the first instance. It’s not always the case (at least in the B2B world) that the users are also the buyers.

(Sure, at some point the product manager may be thinking: “How can I improve the purchase process for my product?” Chatting with the various people involved in a customer’s purchase decision would help the product manager to understand what makes them tick, but this is more about understanding buyer’s needs and processes, not pitching product at them.)

By and large the best way to increase the odds of a product sale is to have a good product to begin with. And that comes from understanding and meeting users’ needs.

Don’t derail my deal!

One of the most common reasons I hear for the sales team blocking access to the customer is that they’re afraid that product team’s user research will upset potential deals.

I’ve yet to meet a product manager that would wilfully sabotage sales of their own product. If a deal does go away, it’s far more likely that this was because the customer felt that that offer wasn’t what they were looking for, rather than because of an ill-chosen word by a product manager.

Nevertheless, some prudence and sensitivity to ongoing commercial negotiations is always a good idea, so if you see the sales team getting twitchy about a particular prospect, maybe skip over that one. There should be plenty others in your target market to speak to.

How a B2B product team should be working

Each of these examples are symptoms of a more widespread condition: a product team not being allowed to be a product team.

Ideally a B2B product team should:

have direct, unfettered access to both potential and existing customers and users, outside of commercial discussions;

not have to fulfil the role of sales support, either pre- or post-sale (there is value in this function, it simply should be a different team providing it);

have authority over their products’ roadmap and to veto one-off products, features or solutions before they’re sold to a customer; but

be able to assist the sales team by sharing insight into the market problems that can be solved by existing products.

Keep up! Product management has evolved

Many companies haven’t realised the role of product management has changed dramatically over the last twenty years. It’s evolved from being a profession characterised by strict process adherence and focus on technology to one that’s passionate about understanding and solving user problems with empathy, agility and a more scientific approach.

With that in mind, it’s no wonder that so many companies, particularly large ones, are only now just beginning to recognise the untapped potential in their product teams.

But we’re not there yet. Partly standing in the way of this evolution is a chicken-and-egg problem: product teams at these kinds of companies tend not to be sufficiently empowered to change their role and responsibilities.

It’s not a lost cause, though; there are things you can do.

Play internal politics to win

Kevin Spacey as the manipulative Frank Underwood in Netflix’s House of Cards. Don’t be THAT political.

Whether you like it or not, where there are people, there’s politics – especially in companies.

As a product manager, you should have a few advantages over the other players in this game: objectivity, evidence and empathy. So try this:

Map out your internal stakeholders – think about who’s influential in the company and interested in what the product team does. Understand who’s pro-product and who’s not.

Figure out stakeholder needs and goals and how a more empowered product team would help them to achieve what they care about. If you can prove this to them with things you’ve already done, even better.

Enlist their help as champions for the organisational changes the product team needs.

A government minister should look at the alpha and say: “I want one of those”.

There was no way we’d get permission for the real thing unless the customer had that reaction.

In other words, while the alpha of GOV.UK may have been tackling a selection of actual user problems (advice when you’ve lost your passport abroad, and so on), the most important user persona for the alpha was in fact ‘the influential minister’. Once they had the support of the ministers, they could really start to solve user problems.

Call it playing politics, but it ultimately enabled something very beneficial for users to happen.

Points to remember:

Think about how you would identify and win over influential stakeholders in your company to build a better product team.

How could you allow stakeholders to experience first-hand the benefits of a different approach to the product team?

Get over your Cassandra complex

Martha Lane Fox’s letter to Francis Maude advocating what would eventually become GDS

If you know the story of GDS, you’ll know that it was Martha Lane Fox who convinced the UK Government to establish GDS in the first place and give them permission to work in a different way. This brings us nicely to the second way to make change happen in your organisation: bring in a respected, external expert.

The expert may well be making exactly the same points in favour of empowering the product team as you have, but their words will carry more weight because they’re seen as an expert. This is another cognitive bias known as the halo effect.2

In Greek mythology, Cassandra, the daughter of King Priam of Troy, was blessed with the gift of prophesy but cursed with never being believed. She correctly foretold the fall of Troy at the hands of the Greeks, but nobody would listen.

As someone who’s at different times been both fighting for change within an organisation and that external product management expert, I truly appreciate how incredibly frustrating it can feel to be forever speaking the truth without being taken seriously.

If you feel like you’re getting nowhere fast, change tack. Try making your point more convincingly with evidence – show, don’t tell – or bring in an external voice to make your point for you more effectively.

Points to remember:

Consider bringing in an external voice to help win over the influencers and decision-makers in your organisation.

Try not to be frustrated if decision-makers are more influenced by external voice over yours – this is cognitive bias at play.

Wrapping up

Because sales teams use commission as an incentive, this tends to be what drives their behaviour. If you want to change their behaviour, change the incentive.

A sales conversation is not the right context for a customer development discussion. A product team needs direct access to its users and customers.

Effecting change in your company without authority means you need to understand the needs and aspirations of your influential stakeholders to make them your champions.

Sometimes you need to use the halo effect of external voices to get people to listen to the same good points you’ve been making all along.

Understanding why particular dysfunctions have crept into a B2B company puts you in a far better position to set about eradicating them. True, it will be hard work and take time for a disenfranchised product team to gain trust and authority, but it’s by no means impossible.

I’ve only ever worked with one sales team that would genuinely recommend other vendors’ products if they were more appropriate to their customers’ needs. (At Zeus Technology, long since acquired.) Funnily enough, they had a tremendously good relationship with their customers, who would contact our sales team first before making any purchasing decision. ↵

As an aside, bringing in actual users to describe how painful the problem you’d be solving is for them, either in person or via video clips, can also be incredibly powerful when you’re making the case to create a product or deliver a particular new feature. This is less about the halo effect, more about triggering empathy with the decision-makers. ↵

]]>http://www.mindtheproduct.com/2016/02/stop-common-b2b-dysfunctions-product-team/feed/0http://www.mindtheproduct.com/wp-content/uploads/2016/01/EarsSteam1.jpgLimiting costs and waste when developing digital productshttp://www.mindtheproduct.com/2016/02/limiting-costs-and-waste-when-developing-digital-products-2/
http://www.mindtheproduct.com/2016/02/limiting-costs-and-waste-when-developing-digital-products-2/#respondTue, 02 Feb 2016 12:05:23 +0000http://www.mindtheproduct.com/?p=7791Reid Hoffman once remarked, “As the networked age has increased the competitive importance of speed, the key secret is now scaling up at speed.” In other words, the internet has enabled consumers to rapidly and easily access and assess new technologies that in turn become exponentially more valuable via network effects. It’s therefore more important […]

Reid Hoffman once remarked, “As the networked age has increased the competitive importance of speed, the key secret is now scaling up at speed.”

In other words, the internet has enabled consumers to rapidly and easily access and assess new technologies that in turn become exponentially more valuable via network effects. It’s therefore more important than ever to get a validated product to market and iterate effectively before the competition. Therein lies the potential and promise of lean methodologies: the ability to learn what users want in the most efficient manner possible.

But that begs the question: from a practical perspective, what progress has product management as an industry made to reduce the waste during throughout the development lifecycle? And what opportunities are there still to improve? We asked more than 100 product managers to establish some benchmarks, and we found five points of interest.

1. Moving fast isn’t cheap

Contrary to what you may have thought, large organizations on the whole don’t take longer to develop digital products than smaller, supposedly more ‘nimble’ companies.

But that speed comes at a significantly higher cost. And in case you’re wondering if product teams have been able to reduce monthly costs by spreading development out over a longer time horizon, just the opposite happens.

As project durations increase, apparently so does complexity which leads to additional costs. Product managers at large organizations should expect that moving faster will come at a cost, and that the best way to lower costs is to decrease the scope of projects into smaller chunks.

2. Building products in-house can reduce costs

In our study we found that more than 80% of respondents develop products in-house while less than 20% outsource to agencies for either parts of or the entire process. Making the digital investment in digital product capabilities seems to be a priority, and it costs less on average per month.

Although building product development capabilities in-house is capital and effort-intensive upfront, it could pay off if your organization intends to invest in developing more than just a couple products.

3. Investments in tools grow as companies get bigger

Of the tools our respondents reported most commonly using, the top 15 were dominated by project management, collaboration, cloud, and source code management. And spending on tools begins very modestly before increasing rapidly with company size.

Interestingly, the percentage of respondents who reported “I don’t know” also spiked in step with number of employees. For large organizations, product managers aren’t necessarily expected to budget for tools, and it would seem that sharing tools and resources across the organizations becomes increasingly common. Considering tools that can scale with the organization should be a point of focus for product managers in growth stage companies.

4. Engineers are apparently chief estimators

When it comes to budgeting, over half of our respondents rely on an estimate from engineering teams, despite the fact that such estimates are notoriously unreliable. Best practice would dictate an iterative approach to budgeting, so that products can be validated in steps, but only 12% of respondents reported budgeting that way.

In the coming months, we’ll further explore if budgeting methodologies have any correlation with product development efficiency. For now, we know that product managers with iterative budgeting structures are a potentially cutting-edge minority.

5. The stress of failure isn’t confined

We asked product teams to tell us about the other departments that were impacted by a recent product failure. Marketing and sales departments were the most commonly affected, while the C-suite was surprisingly insulated.

No matter how many best practices you adhere to, failure is always a possibility. Product managers that want to limit the potential fallout would be wise to build rapport and buy-in from the teams that could be seriously impacted (not to mention the fact that sales and marketing teams are also instrumental to a product’s success).

Where do we go from here?

The findings above from our report provide insight into how product managers are currently working toward and/or missing opportunities for limiting waste in product development. As speed to market becomes increasingly important, it’ll be worth tracking these benchmarks in the coming years to better identify how companies increase efficiency. In next year’s report we’ll be looking for indicators to determine whether large organizations are able to find ways to develop products quickly without encumbering proportionately large costs, and whether budgeting methodologies will evolve with lean methodologies.

]]>http://www.mindtheproduct.com/2016/02/limiting-costs-and-waste-when-developing-digital-products-2/feed/0http://www.mindtheproduct.com/wp-content/uploads/2016/01/AlphaUS-DigitalCost-5.pngHooked – or How to make products and influence peoplehttp://www.mindtheproduct.com/2015/11/hooked-make-products-influence-people/
http://www.mindtheproduct.com/2015/11/hooked-make-products-influence-people/#respondThu, 26 Nov 2015 09:30:15 +0000http://www.mindtheproduct.com/?p=6381As Head of Product at WorldRemit I’m always looking for new ideas and inspiration. Who better to turn to than a man who has successfully sold two start-ups and lectured at Stanford on business and design? So a few months ago I bought Nir Eyal’s book Hooked. Hooked promises to teach readers how to build habit-forming products. The underlying model of all […]

As Head of Product at WorldRemit I’m always looking for new ideas and inspiration. Who better to turn to than a man who has successfully sold two start-ups and lectured at Stanford on business and design? So a few months ago I bought Nir Eyal’s bookHooked.

Hooked promises to teach readers how to build habit-forming products. The underlying model of all habit forming products, Eyal says, has four steps — trigger, action, variable reward and investment. Here’s my take on the model, focussing on the ideas I found most valuable as a product manager and those that were least convincing.

The Hook Model

The first two, trigger and action, are pretty common sense. The trigger is the catalyst that causes a person to use your product and it can be internal or external. For example, an internal trigger to use Facebook could be boredom or loneliness and an external trigger could be a notification saying you’ve been tagged in a photo.

The action is whatever a user does to engage with your product in hope of a reward, e.g. opening your app. The Fogg behaviour model explains that a person takes an action only when all of the following are present:

Sufficient motivation to take the action

Ability to take the action

A trigger to take the action

Focusing on the ‘ability’ part, Eyal discusses something that all good product managers already know: if your product isn’t extremely simple to use, no amount of triggers (e.g. marketing) will make it popular. In the action section, he also gives a brief run through of some persuasive techniques that play on cognitive biases, like the anchoring effect. If you’re interested in these, you can find many more in Kahneman’s Thinking Fast and Slow.

For me, the really interesting part of the book starts when he gets onto the idea of variable reward. The theory is that a variable reward keeps users coming back more often than a fixed reward. This is counter-intuitive from some angles: if you could produce a product that predictably delivered a great reward, it would probably get boring more quickly than a product that sometimes missed the mark. Presumably this explains why gambling is more exciting than receiving your monthly paycheck.

In fact, neurological researchers have found that our brain is stimulated not when a reward is received, but rather in anticipation of receiving a reward. In a study, pigeons who reliably received food as a result of tapping a lever, tapped the lever dramatically less often than pigeons who only received food after a random number of taps. The takeaway here is that you can maintain user interest in your product by sustaining variability.

Eyal outlines 3 different kinds of reward, which he nicknames rewards of the tribe, hunt and self. Rewards of the tribe are social (likes, upvotes), rewards of the hunt are about acquiring cash or information and rewards of the self are about the satisfaction of mastery or completion (completing all stages in an online learning program).

The section on user investment in a product is the most interesting of all. The idea is that a user will keep choosing your product if they’ve put some investment into it, for example gaining followers on Twitter, entering and saving their card details on an ecommerce site or reaching a high episode on Candy Crush Saga. There are also cognitive biases at play because, for example, users have a tendency to overvalue their own work — which is why we all feel so attached to the Ikea furniture we build.

Eyal explains that when a user has just enjoyed their reward, they are primed to reciprocate and put a little more back into the product, even set up their own trigger for the next use. I found this to be the single most useful insight from the book, and I rushed into work the next day thinking of ways we can help users set up their own triggers after they’ve completed a money transfer. The resulting feature, letting users set themselves a reminder to send to the same recipient again on a given day, has been hugely successful at driving reengagement with our product.

I’m with the Peddlers

My major complaint with the book was the ‘Manipulation matrix’ in which Eyal talks about which kinds of products it’s morally right to build. He asks two questions of a product:

Does it materially improve the user’s life?

Would the maker use it herself?

On this basis, he criticises people who build products that materially improve users’ lives, but do not use their own products, calling them ‘Peddlers’ and reserving praise for people who solve only their own problems.

Hold on. Software engineers, designers and product people are drawn from a tiny cross-section of the population. If they don’t look further afield than their own problems, surely they will only produce a very narrow range of products.

The problems of this approach are nowhere more obvious than in digital health products, which time and again are aimed at already fit, 20- to 30- somethings because the product designers are building for themselves. Consequently they are missing the chance to build for people with serious health conditions who could benefit the most from mobile monitoring and health information tools (great article on this here).

In government, I worked on services for user groups including prisoners and National Health Service nurses, neither of which groups I, or anyone in my team, had ever belonged to. But both definitely deserve to receive the benefits of technology just as much as people who fit the profile of the young, affluent, healthy, white, male people (on average) who design and code products. Sure, you might have to work a bit harder to understand users who are different from you, but that’s what user research is for.

Conclusions

Before you pick up this book, it is worth considering whether you’re even trying to build a habit-forming product. Not all successful products are habit-forming. For example handy.com — a great startup through which I found a cleaner — does not need me to make using its website into a habit.

It also strikes me that the idea of building a habit-forming product through variable reward is particularly relevant if you rely on revenue from advertising, so that you need to keep capturing a user’s attention with content. If your business model is ecommerce, delivering a consistent reward every time is probably a more compelling proposition for your users.

Overall, though, I thought it was a helpful, thought-provoking book with a nice blend of theory and practical advice. I’d recommend it to product managers in any field who are thinking about how they can get their users to keep coming back. You can also watch his talk from MTPCon last year to hear the model described in more detail.

I’d be interested to hear from any readers who’ve put his ideas into practice, or who are looking for ways to build habits in their products.

]]>http://www.mindtheproduct.com/2015/11/hooked-make-products-influence-people/feed/0http://www.mindtheproduct.com/wp-content/uploads/2015/10/Book-3.jpgUsing OKRs to focus on customer problemshttp://www.mindtheproduct.com/2015/10/using-okrs-to-focus-on-customer-problems/
http://www.mindtheproduct.com/2015/10/using-okrs-to-focus-on-customer-problems/#commentsTue, 20 Oct 2015 08:12:43 +0000http://www.mindtheproduct.com/?p=7329It’s that time of the year again. You need to set your team’s OKRs (objectives and key results) for the next quarter. What should go in there? What shouldn’t? What are you going to focus on? Here’s a quick look behind the curtain at what we’ve learned while setting them and making it effective at […]

It’s that time of the year again. You need to set your team’s OKRs (objectives and key results) for the next quarter. What should go in there? What shouldn’t? What are you going to focus on? Here’s a quick look behind the curtain at what we’ve learned while setting them and making it effective at YPlan.

Objectives and Key Results (OKRs) is a system for setting and communicating goals and results in an organization. OKRs are a simple way to create structure for company, teams and individuals. If you don’t know what OKRs are or don’t use them at your company have a look at this presentation by Rick Klau from Google first and you probably will.

Our initial attempt at implementing the OKR process turned out to be very “action” focused. It’s not surprising, because we’ve arrived there after periods of company effort focused on one or two very high level metrics. Having a single KPI (key performance indicator – e.g. net revenue or total number of transactions) for the whole company didn’t work, because most individuals couldn’t link their direct day-to-day work to that one metric. Being unable to see how your work is impacting the company’s results isn’t exactly motivating. OKRs, on the other hand, gave everyone 4-5 objectives with 4-5 key results in each objective to play with and the immediate reaction was putting “actions” there (build feature X, close N partners, spend Y$ on marketing to get Z new customers, etc.).

We quickly learned that this approach led to a lot of abandoned / half-finished projects and emphasis on activity rather than outcome. Everyone could now say that they achieved a bunch of actions as per their OKRs set at the beginning of the quarter. However, whether these actions led to any desirable outcome wasn’t at all clear. Typically it didn’t, but hey, at least we’ve carried out the actions we planned, so it’s OK? It’s obviously not OK, and as a result we ended up with an overall lack of focus and lots of time wasted on things which didn’t matter.

Clearly, that wasn’t what we wanted to achieve. Even though it was better than a singular company KPI, and people now had a better idea of what they were supposed to be doing it still wasn’t clear why they were doing it. Going for “actions” is also very susceptible to top-down planning forces, where a manager assigns a list of tasks to an employee without an opportunity for them to have a say in what should be done instead.

So the following quarter we tried to focus on outcomes rather than actions or features. It was then the responsibility of each individual to sit down with their manager and figure out what actions should be done to reach a given outcome. Note that the “KR” in OKR stands for “key result” not “key action”. This approach turned out to work much better, because it stressed the importance of achieving a certain objective, rather than spending time carrying out activities. At the same time it gave individual employees space to come up with that action list themselves and ultimately they are in the best position to know what needs doing.

It was a big improvement over our first iteration, but the resulting objectives still ended up being a rather disjointed set of statements. They could have benefited from a more coherent direction and overarching strategy behind them. Quite a few of them still felt very activity centric, in other words, formulated so that only a particular activity would suffice.

Another problem we had with action-driven or outcome driven OKRs was that all these outcomes were company-focused. For example we’d want to improve gross revenue of the business or make sure that we work with a large number of event partners and so on. While not bad outcomes on their own they really do not guide employees and managers around their day to day efforts (what is the marketing team supposed to do in order to grow gross revenue? Does that play well with what sales team is going to do? When they have a discussion and try to coordinate their actions – how do they choose what to do?).

To address all these challenges we decided to step back and go back to basics. Whichever way we looked at it was always our customers who were rewarding us with their business, so our best bet is to solve their problems as well as we can. So we simply focused on solving our customers’ problems.

That completes the whole circle and helps us set our OKRs:

We think that our customer has a problem. We name that problem. (example: “Discovering and booking events on mobile is a pain”).

We figure out what the outcome needs to be to make us believe that this problem is solved. (example: “Our customer is going out N times a month, they should use our mobile app at least M times a month to help them go out”).

We list the actions we think will address that problem. (example: “Have all venues and events in the city on the app, make sure customer doesn’t need to check other sources of information about the events in app, all events in the app are bookable, etc.”).

We then work on these actions in an agile way by raising hypotheses, testing them and iterating quickly. Steve Blank describes this process in more detail here, but in a nutshell it boils down to picking hypotheses (or, plainly speaking, guesses) which help to validate our vision, crafting experiments to figure out if our guesses are valid or not, running those experiments and gaining new insights. For example we looked at validating whether customers of other lifestyle companies would be interested in booking events via YPlan. We wanted to experiment with partners linking back to our events from their websites or emails and see whether anyone would click on them. Instead of building complicated IFRAME / JS affiliate integrations we opted out for a simple image with a link which allowed us to check overall click rates and save tons of development time while validating demand for the feature.

So now “objectives” in our OKRs are focused on customer problems and “key results” are focused on outcomes, measuring how well we’ve solved a given problem. Focusing on customer problems helps us clarify our thinking and helps us focus on what really matters. It also quickly shows us which of the outcomes are important and which aren’t.

Knowing what customer problems we’re solving has helped us focus our teams too. Mentally connecting your day-to-day work to a customer problem you’re solving is very easy (especially in YPlan’s case where every single employee is also a customer) and helps to keep everyone motivated.

Hopefully this approach will help you too in your next OKR planning session!

]]>http://www.mindtheproduct.com/2015/10/using-okrs-to-focus-on-customer-problems/feed/6http://www.mindtheproduct.com/wp-content/uploads/2015/10/objectives.jpg5 Essential Elements of Perfect Product Messaginghttp://www.mindtheproduct.com/2015/10/5-essential-elements-perfect-product-messaging/
http://www.mindtheproduct.com/2015/10/5-essential-elements-perfect-product-messaging/#respondWed, 07 Oct 2015 16:00:23 +0000http://www.mindtheproduct.com/?p=7233One of the first things that I think about when launching a new product or service is how do we get people to notice? How do we get people to come? Just because you offer something wonderful and that you are passionate about does not mean you will instantly attract customers. Building a marketing message […]

One of the first things that I think about when launching a new product or service is how do we get people to notice? How do we get people to come? Just because you offer something wonderful and that you are passionate about does not mean you will instantly attract customers. Building a marketing message foundation that includes your core purpose, mission and values will help position your product for success.

So, where do you start?

Before you spend endless amounts of time and money chasing the new, shiny marketing activity, identify the true benefits of your product or service, differentiate yourself from the competition in a very clear, defensible and monetarily productive way and give your product an identity that carries throughout your marketing efforts. You will find marketing your product or service much easier when you consistently execute a concrete marketing message across all communication channels.

Without a doubt, there are many elements that go into asserting your product’s presence and getting your customers to notice, such as a website, events and ads, but these 5 foundational elements will help you develop your fact-based product story.

1.Who is the right target market for your product?

Identifying your target market is an essential element of message development. However, it’s likely you will know a lot about your target audience before you even begin working on product messaging. Studying your target market is a critical piece of the entire product development lifecycle and understanding them ensures you are building the right product or service. Your target market is the primary group of people who need and utilize your product or service. These folks personally benefit from your product in some way and your job is to identify their demographics, such as age, education and income; psychographics, such as values, interests, habits, likes/dislikes and personality traits, as well as how and where they “shop.” Your target market may be one or more specific groups. Nevertheless, understanding everything you can about the folks you will target with your products/services is essential to getting them to engage and attracting them with your marketing message.

2. What pains are your customers experiencing?

Similarly to understanding the demographics and psychographics of your target market, understanding their pain points is something you’ll likely consider very early on in product development. Fortunately, you’ll then be prepared when it comes time to develop messaging. One of the best ways to get people to notice your product or service is to position it as a solution to their real or perceived problems. This might be a true problem, a need or a desire. Keep in mind that it’s much easier to address a need that exists in the current market than it is to convince people they have a need. But, if you can create a need for your product by demonstrating that it relieves whatever pain ails them, you instantly inspire them to purchase. Sometimes the pain points you address are obvious, but others are a bit ambiguous. Talking with your customers, learning about their lifestyle, work environment, motivations and goals will help you identify why your customers are better off with your product.

3. How do you solve their problems?

Now that you’ve identified your target market and the pain points they have, it’s time to solve their problems. Although your product or service is an important part of your business, it’s only a small part of your marketing message. This means leave out the vague feature and function lists. Oftentimes, marketing materials will recognize a problem, endlessly list features as the solution and then promise loads of benefits. What is missing is a simple, succinct introduction of what you offer that solves the problem of your target market.

4. What benefits do you offer your customers?

In order to drive interest in your product or service you must clearly articulate the benefits it brings to the table. Features are not benefits and they don’t tempt customers to purchase your product, so leave the features for something else. Benefits provide the customer with value. You can identify the benefits of your product or service by asking yourself (or even better, your customers) how value is derived from various features or the product overall. The goal is to drill down to the ultimate result that your product will have on your customer’s life, job, family or something else of importance. This may be time savings, more quality time with children, greater wealth or increased happiness. Utilizing a benefit driven marketing message will ensure you inspire your target customer to take action.

5. How is your product different (and better) than the competition?

Finally, what is it that makes you special and unique to your target market? It’s your job to explain to your prospective customers how you address their problems better than your competition. Understanding who your competitors are, what they offer, their prices and everything you possibly can about their business, product or service, will not only help you differentiate in your marketing message, but also arm you with the intelligence you will need during the sales cycle. Positively distinguishing your product or service from others in the same market will help you appear much more attractive to your ideal customer.

An Example Imagine you have developed a solution that allows restaurant customers to order their meals using an iPad that is mounted at each table within the restaurant. In order to attract the right customer, you have to understand the intricacies of the product and determine who your ideal buyer will be. In this case, the iPad contains the restaurant’s entire menu, allowing each customer to place their order as if they were making a purchase on Amazon. The order is communicated electronically to the kitchen staff and then a server delivers the meal to the customer’s table. Who is the likely buyer of this product? Well, we know it is for restaurants, but are their specific sized restaurants that will not only benefit most from a product such as this, but be able to afford and implement the solution? Maybe, larger corporation chain restaurants are your ideal customers. Now we need to know who in these large chain restaurants make the decisions. There is likely a business decision maker, such as the Director of Operations and a technical decision maker, such as IT Management.

Now that you’ve identified the ideal target market and buyer, it’s time to identify their pain points. Some pain points may be that customers have been complaining because service is too slow and too many mistakes are made with orders. With the iPad menu and ordering product you are able to solve these problems by removing humans from the ordering equation and eliminating mis-communications between servers taking orders and kitchen staff. With this solution comes a huge benefit of increased customer satisfaction.

Distinguishing yourself from the competition can be a bit tricky because you need to identify, research and analyze your competitors in order to successfully differentiate. The main differentiator for the iPad solution may be price point, or it may be that it seamlessly communicates with kitchen staff ,or perhaps customers can pay using their credit card directly on the iPad.

Conclusion

The key to building a strong foundation before launching your product or service is to take the time to think about your ideal customers, the problems they face, how you can solve those problems, the positive impact you have on their lives and how you are going to help them in a way that’s different from the competition. These steps are essential pieces to developing clear and valuable product messaging. Not only will your customers clearly understand what you offer, but your team will thank you when they are confidently delivering a consistent story when speaking with customers.

Although we’ve discussed essential elements of product messaging, each business is different and may follow a formalized process that mixes in additional elements. What other advice do you have for product marketers when they are developing product messaging?

]]>http://www.mindtheproduct.com/2015/10/5-essential-elements-perfect-product-messaging/feed/0http://www.mindtheproduct.com/wp-content/uploads/2015/10/12482671445_8bdcc0103a_k.jpgHow to Avoid a Product Manager’s Worst Nightmare – Part 2http://www.mindtheproduct.com/2015/08/how-to-avoid-a-product-managers-worst-nightmare-part-2/
http://www.mindtheproduct.com/2015/08/how-to-avoid-a-product-managers-worst-nightmare-part-2/#respondMon, 17 Aug 2015 13:12:09 +0000http://www.mindtheproduct.com/?p=7118In the first part of this article I looked at some of the ways in which product managers can prevent and mitigate the risks of every PM’s worst nightmare: a failed product launch. Now I’m going to talk about some of the other ways you can use careful planning, hard work and strategic insight to […]

In the first part of this article I looked at some of the ways in which product managers can prevent and mitigate the risks of every PM’s worst nightmare: a failed product launch. Now I’m going to talk about some of the other ways you can use careful planning, hard work and strategic insight to ensure you can prevent product fail situations.

Plan for Performance and Stress Testing

Product managers must understand the impact to customers when their product is down. For example, if my system fails, will businesses cease to operate? Will electricity go down? Will people’s lives be in danger? The bigger the impact, the more you have to plan for performance and stress testing.

As a product manager, you also need to understand your audience and the overall usage of your product. This understanding should be part of the product requirements. You should be able to answer questions like:

Will we have 100 or 100,000 concurrent users?

Which times of day are more likely to have peak usage?

What redundancy and elasticity specifications does the product need in order to meet demand at peak times?

Understanding the constraints is the first step. The next one is to come up with a plan to test them and ensure you’ll be ready to handle them when they occur. Make sure to have some projections on how your adoption will grow and how your infrastructure needs to scale in order to meet that demand. Chances are you’ll be way off, but you need to start somewhere.

Planning for performance and stress testing should be part of your standard process, and not a one-off exercise. Performance testing must be done in every sprint, and it should be done in an environment similar to the real world. Anything less, and you risk maxing out your website very fast. The performance team should have their own stories in the backlog and should have deliverables for each sprint. Additionally, I recommend doing end-to-end performance testing several times before the release. Which brings me to my next point…

Allocate Time for Integration Testing

Even though Agile promotes creating production-ready code on every sprint, the reality is that it is very hard to get there. If you have a big Development team, each “Agile Pod” might be able to test their part of the code, but there is no guarantee that everything will work flawlessly when you merge the code of hundreds of developers.

To mitigate this risk, I recommend putting aside at least one sprint for integration testing and stabilization before every major release. The goal of this sprint is to stabilize the system and get it ready for production. No new features will be developed during this sprint.

On top of the technical challenges associated with integration testing, be prepared to convince your Executive Team that no new features are going into the product during that final sprint. They might not be happy, but it’s our job to educate them on the process and help them understand that in the end, this effort will benefit the product, the users, and the company.

Communicate Delays

Let’s face it. Delays happen. Building complex products is hard, and it is not an exact science. Many things might come up, and delays are likely to occur.

When faced with a delay or any other roadblock, it’s imperative to have open communication with the Executive Team. Sponsors need to have timely access to information so they can make decisions that might affect the whole company (not only your product).

In this scenario, take advantage of Agile and use the end of each sprint to inform your executive team about the progress, and more importantly, about whether the product is on track to meet the deadlines you agreed upon.

It’s Better to Delay Than to Implode

If after all these precautions, you realize that your product still won’t be “ready” by the deadline, then you need to make a decision: to push the release out further or to cut scope to ensure that at least something is released. Notice that I say “ready” in quotes, meaning that it’s up to you, along with your team, to determine what ready means. You can play with the scope and with the timelines, but I do not recommend playing with quality as a variable to meet a deadline. That’s how product management worst nightmares become a reality.

I’m not saying that delaying is easy, but it might be less expensive than pushing forward with a faulty product. To make these decisions/recommendations, it’s important to understand both the technical and business side of your company, so you can understand the impact even before you make the recommendation to your Executive team.

In Summary

At the end of the day, it’s the product manager’s responsibility to bring the product to light. Failure to launch can be a disaster not only for your company, but also for your career as head of the product. Luckily, many of the risks can be mitigated with good planning, foresight, and great communication.

Do you agree? I’d love to hear your own experiences of mitigating product failure risks, or your top product success tips in the comments.