Posted on

Is your user story really about the user?

Once upon a time, in a land far, far away, lived a grumpy old wizard who loved spending time throwing stones at little kids who played near his mansion…

is-your-user-story-really-about-the-user

In just a few words, good stories transport you to a different place, stoke your imagination & involve you in the life and activity of someone you don’t know about. Almost immediately you begin forming an opinion about the key characters.

I love stories.

I was very excited when I first came across the term user story in Agile. This was not a user interaction, or a user feature. It was a story.

Ideally, the story would describe the user, his/her context, problem and gratification. It would make the user alive to the team trying to help him.

Sadly, from what I’ve seen across companies, not many user stories are written well.

Badly written user stories either have generic description of the user of the product, or end up being feature specs (eg: As a user, I want a green button labeled ON)

There are usually two reasons for bad user stories:

  • The product owner doesn’t know much about the user and/or
  • The engineering team treats the user story as a specification document

The user story should describe what the user wants to do. Instead, it ends up being whatyou want to do for the user.

Product owner and user research

I had earlier written about Agile as a concept vs. Agile as a process. A key limitation in treating Agile as a process is that the product owner is driven by the engineering team.

The key determinant is to keep the engineering teams executing, so the product owner ends up spending a lot of time ensuring the backlog is filled up in advance. This leaves little or no time for understanding the user.

Constrained by time, the product owner makes a generic outline of the user and anchoring stories around this.

If you treat Agile as a concept, the product owner is supposed to represent the customer’s voice in the development process. The product owner has to know his user’s needs well.

Many product owners, especially in B2B scenarios, end up figuring out user needs through secondary research, or based on quick conversations with a couple of target users.

Nothing is more dangerous (in the Agile environment) than a product owner who has limited knowledge about the user, but considers himself a representative.

Why?

Because the team ends up building a product that no user may end up liking. During the development process, the product owner argues eloquently about user needs, often mistaking that his/her view concurs with the user’s view. In the end, the product owner is satisfied with the product; no user is.

Users in real world often surprise you. If you’re in tourist mode, you often end up with the wrong conclusions.

I was once involved in building a mobile app for a low-end phone. I asked the product owner to draw some outlines of the user’s constraints and needs. When we reconvened, he came up with an observation that users were not bothered with data costs. “After all,” he said, “what difference does Rs. 10/- make to the mobile bill?” He was basing his argument on a chat with a couple of users across stores and one store employee.

Many of our target users were on pre-paid accounts, and rationed their mobile usage. They had dual SIM phones, and kept one slot for switching carriers who gave better deals. They would route incoming to the fixed SIM, and keep swapping the other SIM based on carrier packages where they could save money.

While we didn’t go about doing a detailed user study on this, I was able to cull information by speaking to a few college students, who were part of the TG, and triangulate it with information from friends who worked at carriers.

In this case, Rs. 10/- was an inconsequential amount to the product owner, but was a huge consideration for the actual user. If we had ended up missing this, we would have built a product that users would quickly have rejected due to high data demands.

Many engineering teams, especially those transitioning to the Agile mode of working, often insist on the user stories being complete, i.e. specified so that they can efficiently code out the solution.

This results in the product owner spending a lot of time writing and rewriting user story descriptions and acceptance criteria. As development progresses, the story backlog ends up having a lot of technical stories, bug descriptions and engineering terms. And in the process, the focus on the user’s problem is lost.

Ideally, a user story is designed to enable exploration of different ways of solving a user’s problem. It describes what the user wants, and a context in which s/he feels the need. The constraints are written in the acceptance criteria.

Given this, the technical team & designers can now explore multiple ways of solving the problem. The product owner can stay involved to judge which of the solutions serves the user’s need best.

In this approach, the team retains its flexibility in thinking up new ways of solving problems, often discovering better solutions than a didactic way of the specifications written by the product owner.

Of course this isn’t easy. It requires a lot of planning ahead to ensure there’s time for the exploration. It also needs maturity from members of the team. The team has to be comfortable that some of the work they do will be thrown away as they discover new solutions, and not stick solely to efficiency metrics.

Some organizations follow a dual-track method for Agile for this: a delivery and a discovery track. The discovery track is usually a small team that handles the experimentation. These solutions are often quickly tested with real users for quick validation.

One of the best ways I’ve seen to get out of the user story as spec is for the team to decide at the start of the project that they would keep a couple of experimental sprints, where they try an exploratory approach to build a solution based on understanding the user’s context without detailed specifications. Many times, these end up sensitizing the development team to the user they build for, enabling them to think for the user instead of thinking for the project.

One of the key beliefs in Agile is to know the user well, and build a product s/he likes. In my experience, I found that this often is key to building a great product.

I’d love to hear your experiences with user stories in the comments below.

Posted on

Why services firms struggle to build products

I’ve seen this play out so many times over the last few years.

A business leader at a services firm will sit down and talk about how they’re working on a product. S/he will quote the usual mix of arguments – services as a business is struggling; Indian firms have challenges making products but they think they can do it this time; automation/products are key to their future – and finally end by being confident about the potential.

why-services-firms-struggle-to-build-products

A few months down the line, the business leader will lament about how the ‘team’ doesn’t get it, and how tough it is for services firms to think ‘product’. Management will consider hiving the product team off into a separate location, or even moving the product business out as a separate firm.

In most cases, the end is predictable. The services firm realizes that the product business is radically different from what they’re used to. The product experiment they started off with didn’t play out the way they anticipated. They usually shelve the product arm, or make the arm build products only for internal consumption, while their business continues to be services or managed services build on top of the product.

Why do things go wrong?

Most business leaders will reflect that their teams didn’t have the product ‘mindset’, but in reality, there are a combination of factors that affect this.

I’ve listed them in three buckets

  • Product management & skills
  • Sales/marketing
  • Business strategy

Product management skills

Inability to understand market needs

Most services firms are used to a pattern of bidding for RFPs, winning the deal, and then assigning a bunch of business analysts (BAs) to handle requirement gathering.

When they start experimenting with products, they graduate some of the BAs to become product managers. After all, they know client needs, right?

Wrong.

In practice, a lot of BAs struggle as product managers. The challenge is not with their skill or ability, but in their organizational roles thus far.

Most business analysts are used to starting on a specific client engagement, working with IT/business leaders and listing specifications for their teams. Their role involvesefficient translation of existing requirements.

However, for good products, there is no ‘client’ to give requirements. The challenge for product managers is to unearth requirements based on knowing market needs and customers so well that they can design a product without getting a business requirement document.

This is not about not asking customers for what they want (people often state the oft repeated lie of Apple not doing consumer research when this comes up), it’s about understanding the customer requirements better than they can, and coming up with a product design that would suit their needs.

This is one of the toughest steps in the journey, and one that most firms get wrong.

The inference seems simple, but I find that services firms need a lot of coaching on the process to even start thinking along these lines.

The myth of ‘productizing’ services

This is closely linked to the previous point.

Many services firms start thinking of products after they receive requirements for something new from one client (eg: data analytics). They believe they can easily productize requirements to come up with something they can sell to other clients.

This rarely works.

Building for one client often means that your product is so specific to their needs that you will have to make significant changes when you take it to others.

This means making modifications to existing design, that services firms usually agree to thinking they’re doing products. Very quickly, they realize that they’re back in services mode.

What is required is to build something that the clients feel they could adapt to instead of the other way round. That comes only when you can bring in market knowledge into the product instead of just client knowledge.

Lack of product marketing skills

Building a product business is a lot more than just building a product.

In practice, the product marketing team has to spend time positioning the product right, building the right communication stories and getting customers to feel the product is right for them.

This takes a totally different skill set than sitting with the client and getting him/her to sign off on a service delivered. It involves a lot of business storytelling, segmentation, messaging and more.

Most services firms do not have experience with these skills, as their marketing teams have largely been involved in corporate marketing, branding and events.

Sales/marketing

Incentives and organizational enablers

When services firms look at building products, they often ignore the rest of the go-to-market cycle.

For instance, a couple of services firms I know built specific sales teams for products. However, they drew the team members from existing services and presented product selling as a fresh opportunity.

The sales team quickly realized that product selling & business models are very different. Where they could ratchet up millions in sales revenues from a single client (and accordingly, earn their incentives), they now had to spend a lot of time with multiple clients to convince them about licensing deals and the like. This was a lot of additional effort that saw the sales team quickly lose enthusiasm.

In another firm, the product team tried piggybacking on existing sales representatives or account managers. However, they realized that the sales team would often offer the product for free as a sweetener to clients to win deals. After all, their primary aim was to close deals, not sell products.

Existing brand perception

“But we thought you were into <services>. Why are you doing products?”

Products from services firms live in the shadow of the larger brand, and often this gets in the way of customers treating them seriously.

Clients often do not believe that the firm will ‘stick it out’ in the product game, as they are known for services. Hence, they are often reluctant to place bets on products from services firms, even if they have an existing relationship.

The existing brand perception often interferes with the product positioning as well. Rather than flowing as a natural extension of the brand, the product positioning has to dodge references to existing business that may confuse the market.

Business strategy 

Legacy relationships & contractual agreements

Most services firms have signed contracts with clients that clearly state all ownership of data/IP lies with the client.

When they begin thinking of building products, they usually find that even good ideas need amendments to contractual agreements to let them use data. Client account managers are hesitant to get into the discussion, and clients too look at such requests with some reluctance – after all, the benefits for clients is rarely commensurate with the risk.

Risk of new disrupting the old

Many services firms announce their foray into products and platforms with flourish. While this brings their product business into focus, it also serves to threaten existing business lines.

These shifts are rarely easy, and there are often a set of well-entrenched players within the system who are skeptical, scared or both about the new developments. Inability of leadership to place the product offering within the larger organizational context often leads to existing verticals undermining the new efforts, and sometimes, even cheering failures.

Lack of strategic importance in firm’s business

Product businesses need time. Services businesses are about immediate revenue flows.

Services firms often lack patience to wait for the product businesses to steady themselves and contribute to the firm’s bottom line. After the initial buzz, many services firms lose focus on the product business (or treat it more like a marketing/PR exercise) as it doesn’t contribute in significant ways to the company’s bottom line.

In case the senior leadership/CEO has committed revenue numbers to the board/shareholders, there is added pressure to quickly show revenues. This often leads to shadow revenues (accounting for revenues for product usage within firms own services – often leading to double accounting) or drifting to managed services on top of product lines to build revenues.

In both these cases, the focus quickly shifts away from giving the product business its space.

These are factors I’ve observed, and I’m happy to hear thoughts/arguments about the topic. Please leave your comments below.

Posted on

When sales hijacks your product roadmap

Hey product manager, let me remind you of that time when you had the perfect roadmap for the market. You had it all sorted out (finally!) with engineering and were clear about what you’d build. Your teams had already worked on a few sprints and you felt that this time, you’d be able to get the product right.

when-sales-hijacks-your-product-roadmap

But then, your sales person turned up and said ‘I’ve just promised feature x to the client. We have to build it.’

You gnashed your teeth and got into an indignant fight.

The sales person just made your carefully crafted product roadmap look pointless.

How could he do this? You had just sent out your roadmap last month and said this is what he was getting. Why does sales always do this? Why can’t they just sell what you have, instead of pushing for what you don’t?

You take it up with your management, and maybe even the CEO, but finally are told that this client is just too critical, and you will have to build what the sales person wants.

You grimace, and feel all your passion drained out. Ok, you think, I’ll do it, but under protest. It’s my job to get it done, but it’s no fun anymore. Maybe you should just look for another job where they trust product managers over sales….

Let’s break out of the reverie. This is something that happens in a lot of organizations.

Most product managers have an ambivalent equation with sales. They need the sales team to bring in revenues, but hate having to accommodate what the sales persons ask (and always at the last minute at that!).

Is there a way out? Can you safeguard your product roadmap from mutilation?

To be honest, it depends on how your organization is structured and power equations within. But there are things you can do as a product manager to prepare for something like this.

Learn how sales works

A large number of engineers turned product managers look down upon sales as a necessary evil. They’re far more comfortable in the deterministic universe of building a product. Sales seem to be a profession for smooth talkers who care only about their numbers and not about the intrinsic product itself.

Unfortunately, this worldview makes life difficult for all involved, but is like a self-inflicted wound for product managers. You can complain about sales around water coolers all you want, but it’ll help more if you learn to appreciate how sales works.

In most of my product manager trainings, I ask product managers and aspiring product managers if they have worked with sales earlier. Many say that they’ve just accompanied a sales person on a customer visit. Often, they would be briefed by the sales person just before the meeting, and requested to not comment on anything beyond the demo. ‘Leave the relationship part to me,’ the sales person would say. If, during the meeting, they strayed from the brief, the sales person would try gesturing frantically to not say something that puts the deal in jeopardy. They usually walk out thinking that they should just send a junior the next time for the demo.

In my experience, I’ve seen that good product managers have a great understanding of the sales process and see themselves as team players in getting customers to choose your product/solution.

But I also find that most product managers have only a vague idea of how sales works. Sales is also a process, and most good sales folks have a keen understanding of how to get started in the market, generate leads, convert leads into conversations and go through the consideration-preference-sale process. Sales, especially enterprise sales, is a lot more strategy & structured approach than just numbers.

My recommendation to product managers who haven’t been through a sales cycle is to get a buddy in sales, and understand how they work. Not only does it make it easier to talk to them when it comes to client asks, it often gives surprising insights about how your product is used and/or what competitors are building.

Have different versions of your roadmap

Many folks are surprised to hear that you should have different versions of your roadmap. The sales team often uses the roadmap to sooth client concerns on whether your product/firm sees a long term view for something they need to invest in.

If you have the same roadmap that your development team uses, you risk the sales team aggressively committing to features to win the deal. Often, clients are speaking to multiple potential vendors, and there is risk of competitors learning about your product roadmap. There is also a risk that if the client signs off on a deal based on your roadmap, you have very little slack if things go awry (don’t they always?).

It often helps to have a ‘light’ version of the roadmap for the sales team to discuss with the clients. You could share the development roadmap in confidence with sales, but insist that only the light version be seen by clients. That way, the sales person also knows that he can reach out to check if he needs to share something from the development roadmap with clients on a case-by-case basis.

Negotiate

Most product managers know the art of negotiation with engineering teams to get them to agree on what to build. But good product managers also know how to negotiate with sales teams.

What does this involve?

Often, it means having the right amount of flexibility in your roadmap. Don’t look at yourself as a ‘mini-CEO’ who has to call all the shots for the product. At the other end, have your viewpoint that’s not based on what engineering can build or what sales tells you they can sell (this is why it’s important to know your customers well).

I’ve been lucky to work with sales folks who respect a well-articulated viewpoint on why a particular client ask will take the product down a path that will make it difficult to adapt for other changes later.

These conversations take the path of ‘how do we make this deal work?’ What usually follows is a negotiation on what we can tell the client, even if we can’t fulfil all his/her asks. This helps build a joint pitch on what we think is best for your business.

This doesn’t always work, but the process of negotiation with the sales teams often help build respect for your capability and reasoning as well.

Another factor that I’ve found helpful is to have a strong list of priorities for your product, and areas where you can be flexible. That helps in the give-and-take of the negotiation.

You may not always be able to prevent your roadmap from being hijacked, but you can minimise its impact with this approach. I’d love to hear your thoughts on this topic in the comments.

 

Posted on

Do You Need An MBA To Be A Product Manager?

An extremely polarizing topic, the question, ‘Do You Need An MBA To Be A Product Manager?’ is an often asked one on popular forums; the answers range from “No, an MBA won’t help you in any way, and you are better off not spending the money” to “Yes, it’s a must if you want to get hired by large corporations.”

Like most big decisions that individuals need to take as part of their career growth journeys, the answer is really:

It Depends.

Now that may seem like taking the easy way out, but there really is no one single decision that would make sense for every aspiring Product Manager. So, instead of asking if an MBA is essential to become a Product Manager, a better question would be:

What do I lack in my quest to become a Product Manager, and how do I acquire the skills I lack?

When you frame the question this way, you can make a decision that fits your career goals and skill levels, rather than following a generic guideline that may be right for someone else.

A few years ago, getting an MBA was the best way to gain exposure to various business functions and learn skills needed to be an effective product manager. However, there are multiple alternatives available today – working in a startup where every member gets exposed to different aspects, taking online courses, taking specific training programs to build key skills or learn methods, and more.

So, with that in mind, let’s look at some of the skills and qualities you would need as a Product Manager and how you can gain them with/out an MBA.

Joining the dots between Market-Customer-Product-Technology

A good PM needs to map market opportunities, understand customer behavior in the context of that market, visualize the opportunity in the form of the right product – and finally, ensure that the available technology can deliver the product in the form visualized.

An MBA doesn’t teach you to do all of this. However, it can help you learn the tools you need for the first half of the equation, i.e. understanding markets and customers.

Of course, successful managers who do this without an MBA exist, but an MBA can reduce your learning time at work.

The rest of it is a skill acquired over time, learning on the job and supplemented by Product Management training that you can practice at your role.

Communication & other soft skills

PMs necessarily have to work with Sales, Marketing, and Engineering; to do this successfully, PMs need communication skillsbeyond talking – they need to listen, negotiate, harness the power of teams and often, influence using their credibility rather than authority.

Do you need an MBA to acquire these skills? If your communication skills are poor, an MBA can help you polish certain aspects such as presenting ideas well; on the other hand, if you have excellent communication skills, an MBA may not help you much in this area. (And don’t take your own word for it – get an objective person you know to rate your skills).

Product Marketing

Depending on how your company structures its teams, PMs may or may not be hands-on when it comes to Product Marketing. In the Indian context however, most PMs will be deeply involved in some or all aspects of Product Marketing.

This is one area where an MBA can add to your learning, with courses on consumer behaviour, brand management, and marketing communications. Many engineers lack exposure to these aspects of the job, and having some training in them is an asset.

Today, you could also gain some exposure to these using online courses from Coursera or others.

Networking

Till a few years ago, colleges were the best areas to form strong networks. Most of the leading B-schools have strong alumni networks that allow exchange of information about new jobs, and often give visibility into what friends in other industries are up to.

However, today there are a multitude of forums to network within the technology industry like startup events, LinkedIn forums, expert networks and more. While these do not replace the traditional B-school networks, they definitely give a leg up to candidates looking to build their own identity and explore work in other domains.

Graduating from any of the top B-schools could give an edge in getting selected for roles, but a lot then depends on the candidate, his/her domain and functional expertise to clinch the job.

With many startups trying to make their mark in the product space, demonstrating expertise in your known area of work through blogs/forums or by interacting with others in events often throws up job opportunities that you may not be aware of.

The key skills of being a good product manager – intense curiosity to understand how things work, an ability to appreciate context and its effect, the ability to observe keenly, spot opportunities and work to tap them – are not skills that a B-school can teach you.

While a B-school might hone some of your skills, you should take a cost-benefit approach to this and rightly ask – is an MBA worth the money?

Without a huge education loan to pay off, you may decide to take the risk of picking a relatively lower paying job as a product manager for the experience, or maybe start your own firm based on an idea you have.

That would be the first step along thinking like a product manager.