The problem is that these other teams are really busy with their own tasks, focused on hitting their own quotas and goals, particularly Sales. It’s a challenge to make space for internal feedback to Product – but it’s possible!

Similar to my post about product feedback from Customer Support, here I’ll explore the challenges of getting input from the Sales team and how to create a two-way collaboration that benefits both sides.

Understand the other side

Let’s start off with some empathy, shall we?

Often, from Product’s perspective, it seems like Sales just doesn’t see the value in how to get customer feedback. This might be the case. Maybe they don’t think it’s their place, or they don’t think it’s their job. Which is fair! They do have a point.

As a product person, I wondered why other teams wouldn’t take the time to tell us all the stuff they were hearing from customers. It can be frustrating. But in my roles since, I often think to myself, “When am I supposed to do this? They want me to send a bug report or fill a form in a certain way. I haven’t got time for that!”

It’s difficult to find the time and motivation to provide feedback to another team – especially when it doesn’t seem core to your role, and when your pay doesn’t depend on it. 

Consider how your sales team is compensated. They’re often paid by commission, which means their income isn’t guaranteed like yours. If they want to make the amount of money they’re expecting and have planned for, then they better hustle – and stay focused. Keeping differences like this in mind will help as you build a better relationship with the sales team.

So, with that said, we want to do two things:

• 1. Encourage sales colleagues to see the value in sharing their feedback.
• 2. Make it super, super easy for them to do so.

How to encourage Sales to add customer feedback

It’s in their best interest, too!

Explain to Sales how providing customer feedback is in their own best interest. If they’re constantly hearing the same objection, or trying to clarify the same confusion, or whatever the potential customers keep repeating – maybe a tweak in the product would solve it. Passing on that information to Product could save time and energy, allowing them to close more deals.

This is a classic case of putting in a bit more effort now to receive a payoff in the longrun. 

Reciprocity between sales and product

When it comes to the app or the tool, the product team knows what they’re talking about. That’s why they’re so valuable to have on hand for sales calls and demos! The product team’s knowledge will enrich those conversations and help close the sale.

Explain how this goes both ways! Sales needs to be there for Product in return. The sales team knows what they’re talking about when it comes to customer objections and user feedback. Passing along this information will enrich the product team’s knowledge, strategy, and decision-making.

It’s a collaboration. It’s about working together, and it’s got to be two-sided.

Now, if there’s an issue with how to actually provide the feedback, Sales and Product should discuss a process that works for both sides. On that note…

How to get customer feedback from Sales

This is probably the most important tip on how to get customer feedback: make it frictionless! For any of the above efforts to be successful, you need to make the process as convenient as possible. Here are a couple ideas on how to do that.

Provide a template

Templates reduce cognitive load. If you provide a template for bug reports or other customer feedback, then the salesperson just fills in the blanks and submits it. They know exactly what information you need, and you don’t need to chase them up (i.e. annoy them) for pertinent details. That’s a win-win for both sides. 

This is similar to writing user stories, where we recommend choosing one specific story format.

Collect feedback directly in CRMs

One great thing about standar sales processes today is that when sales reps have a call with a customer, they’re logging it in a CRM. These call notes can be written manually or automatically through a transcription service. But the point is: there’s already logging of customer insights and feedback going on! We just need to get it to the right place.

ProdPad integrates with Intercom and Salesforce to do just that! Feedback is automatically fed to the product team, and it’s no extra effort for the salesperson.

Benefits of a Sales-Product feedback pipeline

Putting a feedback process in place, and making it seamless, does take some work upfront. But the result of getting customer feedback will benefit everyone on all sides of the product.

1. It saves time for Sales in the short term (no one will follow up with questions or ask them to resubmit with different information) and the long term (those questions and objections disappear because the product is better!)
2. The product team receives feedback right away – and the evidence they need to act on it! – without needing to follow up or cause friction with other teams. This is another timesaver.
3. Sales feels listened to, Product feels supported. And ultimately, the customers gain from a business that collaborates and continuously innovates on a great product.

The post How to Get Customer Feedback From Colleagues appeared first on ProdPad.

At some point, I switched from a chronological timeline to what was effectively the Now-Next-Later roadmap. This improved our work, our morale as a team, and my own relationship with product management. What a relief!

In this post, I’ll explain some of the pain points and hassles I experienced when I was using timeline roadmaps – and why I had to break up with them. At the end, I’ll explain how you can break up with them, too.

Why deadlines aren’t a good match for Product Managers

I worked in a corporate environment, in a big product management team. It was a high-ticket B2B product, so we didn’t have many customers (dozens rather than hundreds) – which allowed us to have close relationships with them. That was great because we could speak with them directly on a regular basis and understand their needs. We had accurate user groups with well-defined problems.

But the downside of the larger corporate environment, from a product perspective, was that we were less agile and slower moving. My role was to set out the product strategy, but because I knew no better, I put delivery dates on things because those timelines felt reasonable to me. The company could never meet the deadlines, though.

So when we had these regular customer interactions, which often included roadmap presentations, I would use the same roadmap for months on end, presenting it several times in the exact same form. I just changed the dates because as a business, we weren’t quick at execution. So, like clockwork, a couple of weeks before the next customer meeting, I’d take the last roadmap and simply change the dates.

Our customers caught on and they weren’t impressed. Thanks to our close working relationship, they felt comfortable telling us exactly what they thought. And they called us out on this repetitive, perpetually delayed roadmap.

For me as a product person, it felt humiliating. I’d show a roadmap to a room full of people and some would say, “You literally showed us that same roadmap six months ago.” I had to explain why that’s the case, representing a larger business with many moving parts that I couldn’t influence, let alone control. Plus, I knew they were right! But I had to put on a good face for my company.

This is what timeline roadmaps and Gantt charts do to PMs. We get stuck in an awful situation where we can’t get it right! And when we’re stuck in relationships like that, it’s time to break up.

The breakup

The process of switching roadmaps required some vulnerability, lots of discussions, and finally some patience and experimentation. 

Address the problem

I had to tell people the pain that I was feeling, explain why the timeline structure wasn’t working for me, and suggest an alternative approach. 

Get support

Though I initiated the change, I needed to get buy-in from my direct manager, who then helped to socialize that amongst the other 10-15 product managers. Ultimately we all discussed and standardized what we’d try next.

Choose a new direction

We opted for a horizon roadmap, one that closely resembled what we call Now-Next-Later. It was three chunks, outlining objectives that the company will focus on in the immediate, short- and mid-term future – these are the horizons. For example: “Next year our objective is to enter a new niche of the market, so we’re focusing on X. And the year after that, our objective is user growth, so we’re focusing on Y.”

Given the slow-moving, corporate nature of the company, these horizons were still quite long-term compared to today’s tech startups.

But still – horizon roadmaps changed the conversation completely.

By letting go of fixed dates and embracing the inherent uncertainty of product work, we opened up new discussions. We could debate whether our ideas were actually the right things to do, instead of planning on when to deliver what. This gave us more flexibility to pivot or modify the roadmap, according to our current strategy.

Other benefits after breaking up with deadlines:

• The product team was validated! Even though there were still problems in execution, it was now clear that the product team worked well and had a good strategy in place.
• Personally, I didn’t have to feel awkward in front of the customer anymore!

How to make the switch from deadlines and gantt charts

Approach the switch the same way you approach a minimum viable product (MVP). You don’t need to do it all at once! Instead, experiment with your new approach on a small scale first.

For more insight into this process, I highly recommend a talk called “Changing the Weather Inside Your Organization” by Tom Loosemore. He has loads of experience in product management within bureaucratic institutions, famously the least agile. Any question or challenge you face in your company, he’ll probably address.

Last word

Working at ProdPad, other product folks often ask me how they can ditch timelines once and for all. My answer?

Speak up, and start small. There’s nothing to lose.

The post Breaking-Up with Deadlines and Gantt Charts appeared first on ProdPad.

In this post, we’ll cover why support and product should work together, how to train support to collect and evaluate user feedback, and finally how to set up a solid feedback process between the two teams.

Why support and product must work together to solve customer problems

Customer support people are problem solvers, no doubt about it. Their job is to field complaints or difficulties, user mistakes and software malfunctions. And they’re incentivized to solve the problems as quickly as possible, usually under a certain time period: two hours, 24 hours, etc. Closing tickets and customer satisfaction are critical to customer support’s performance metrics.

But what about the customer problems that can’t be solved on the spot? Then product management gets involved.

Indeed, these problems might require a longer term (i.e. more comprehensive or more foundational) solution, perhaps something built by the development team. Once a solution is in place, the support team doesn’t need to field complaints about it anymore.

So, reporting and/or handing over such customer problems from support to product is clearly an important link. A strong feedback loop between these teams can better the product, improve user satisfaction, and increase support efficiency – impacting all the juicy company KPIs that are attached to those.

The key is to get this hand-off right! 

How to train customer support to collect feedback for product

To be fair, it’s not the support team’s day job to collect and interpret feedback so much. And we’re not trying to put more on their plate. Quite the opposite. We’re trying to get to the root of issues, so their job is easier! (It just so happens this makes our job easier, too.)

We can get there by reframing questions and using new techniques. The tenets of this training are to help the customer support team to:

Understand “the why”: how to see customer problems holistically

When it comes to understanding customer feedback, product teams love the 5 Whys method. (In fact, I’ve even used it with my own dad!) It’s a simple one to pass on to the support team.

The method approaches feedback and requests with an iterative round of questioning – and that question is always simply, “Why?” With each answer you receive, follow up by asking “Why?” again, and you’ll peel back the layers of what the customer actually needs.

Focus on problems, not features: how to define core issues

Once we’ve reached the core problem, let’s stay there! Let’s not wander into solution territory or hypothesize how some features could be tweaked to do this or that. We don’t need feature requests, we need well-defined problems.

One way to help non-product people understand this concept is to give real life examples. Specifically, give them examples of when a product feature request has led to something being built that wasn’t the requested feature, but that did solve the underlying problem and in a better way.

Some well-known quotes out there demonstrate this well. And although the quotes might be historically incorrect, their messages still ring true!

“If I had asked people what they wanted, they would have said faster horses.”

Henry Ford (There’s no evidence he actually said this, but it’s a product management maxim at this point.)

and

“The electric light did not come from the continuous improvement of candles.”

Oren Harari

Once the support or success teams get the importance of staying problem-focused, you can give them convenient ways to transfer this customer feedback to the product team.

Use good feedback channels: how to communicate it to product

The final step is to make this collaboration as easy and seamless as possible.

Product people know that the best practice for collecting customer feedback is to offer loads of ways for those customers to actually submit it. There should be an option in the app, on your website, via email, through Slack or social media, etc. If your team is new or just getting started with collecting feedback, have a look at how to set up a customer feedback process.

The same applies to getting feedback from customer support to the product team. Set up several feedback channels for non-product folks to send over the information. The easier it is to share, the more feedback you’ll get. And chances are it will be better quality!

You can use a special email address, a Slack channel, a Typeform, an old-school shoebox with written notes inside. Provide a short template for a “problem-focused” report, so the support rep only needs to fill in the blanks.

Of course, it’s best to automate this step as much as possible. That’s exactly what we’ve done with ProdPad.

Within the tool, we have a Chrome extension, which means that people from Success can quickly write some feedback from their browser. There’s also a customer feedback portal where the support or success teams could add feedback on behalf of a customer.

Essentially, ProdPad is a tool that helps automate the feedback collection process, and then helps product teams manage the feedback through well-designed backlogs and roadmaps. To check it out, you can sign up for a free trial.

The post Solving Customer Problems, Not Feature Requests appeared first on ProdPad.

What is Product Ops?

Product operations is the business function that provides tools, data, and processes to enable product teams to work effectively and bring the right solutions to market. It’s a function that has matured in recent years and is seen as a key component of product-led growth in companies with a strong focus on product management.

One of the earliest questions about product management in a small company is “when do I need to hire a product manager?”. As the company grows, the answer to the next question is “when do I need product ops?” is usually presaged by some obvious signs. Let’s examine a few of them.

Data-driven decision-making vs CEO’s demands

Is senior management making the product decisions? To move quickly in a changing market, product managers need to be guided by data as they prioritize their work. In the absence of data-driven decision-making, teams can become conflicted and base their decisions on opinions, often listening to the loudest voice in the room (the HiPPO or highest-paid person’s opinion). In the absence of evidence, the roadmap turns into a list of features decided upon by senior management. Some of these decisions will be right, but some will be wrong – and that introduces an undesirable element of risk. 

With conclusions drawn from objective data, the best decisions are more obvious, and it’s easier for teams to push back on opinions that have low merit. The role of product ops is to learn about the kind of questions product management are likely to ask and identify the best sources of data to answer those questions. This might involve implementing a product analytics tool or creating reports that provide clear guidance.

Product Discovery vs Product Development  

Are the teams becoming delivery-led and skipping product discovery? Growth may stall when technical teams are in the driving seat. Large and messy backlogs can develop if there isn’t a discovery process to filter the right ideas through to development in a controlled manner.

With a pipeline of ideas progressing through this process, everyone is aware of what’s coming in the coming weeks, and prioritization of the backlog is much easier. Product operations is well placed to select and implement a product management tool like ProdPad that enables the product management process and helps product managers to find the value in a messy backlog.

Infrequent releases vs short iterations

Are there lots of ideas but no action? In any competitive market, quick reaction times are key to solving customer problems. The longer it takes to solve a problem, the more likely that a competitor will disrupt your place in the market. Reducing the time between insight and action is a strong measure of success for any product team – but it’s not always easy for larger, more established teams. 

It’s a cliché but still true – the more shots you take, the more likely you are to hit the net. Rather than planning huge releases with big product changes, lean experimentation allows product managers to learn what works in a short amount of time, so they can adapt as they learn. But managing the experimentation process can be time-consuming and involves measuring outcomes – and this is where product ops is uniquely positioned to help, both with experiment design and with success measurement.

Product Ops and product management process

Are there lots of teams working in different ways and using different processes? When lots of product teams work in isolation, a lack of standardization quickly develops, especially when they’re allowed to choose their own tool stack or way of working. We’ve all seen “combined” roadmaps that look like ransom notes, with different formats, fonts, and levels of details in evidence. 

The phrase “black box” is often applied to product management. Product teams can feel distant from the rest of the business, with other functions feeling out of the loop with what’s going on, or how decisions are made.

Taking the time to understand the needs of multiple teams requires the dedication and neutrality of someone who is focused on achieving company goals, rather than the goals of an individual product team. That’s where the product ops function comes in.

Lack of alignment on company vision

Is there no clarity on why decisions are made? Alignment is impossible if there is no clarity on the company vision and current objectives from the top of the business. Even if vision and objectives are defined, they still need to be communicated in a way that everyone can understand.

By ensuring that all team members have access to the roadmap and the ability to self-serve information when they have questions, a product operations team can reduce friction across the business and encourage team collaboration (and therefore better outcomes).

A disconnect between product and customers

Are the sales and service teams acting as gatekeepers for their customers? Product-market fit, that sweet spot where the product so completely solves its users’ problems that buying it is a no-brainer, is virtually impossible to achieve when the product team is disconnected from customers.  This can happen in large companies where sales and services teams act as gatekeepers for their customers and create a barrier between those who are focused on building new products and the users that they serve. It means innovation is reduced and progress stalls.

Once again, the product ops function comes to the rescue by implementing the tools and process changes needed to encourage feedback from customers and centralize it in a single repository for continuous discovery.

Are you ready to get started? Why not check out How ProdPad Fits with Product Ops.

The post Harness the Power of Product Ops appeared first on ProdPad.

1. Assign responsibilities

Like any process improvement project, assigning roles and responsibilities is vital. Someone needs to own the development of the product feedback process itself – the initial process definition, plus ongoing process improvement. On a day-to-day basis, someone needs to be responsible for reviewing and triaging the feedback that comes in. 

In my experience, it’s common practice to put effort into collecting customer feedback without assigning someone to review what’s been collected. Feedback needs to be reviewed, organized and turned into something actionable. This is a great job for an aspiring PM, or an engaged customer success person, as it’s a good way to see exactly what people are saying about your product and to learn about user problems. But reviewing feedback can be time-consuming work, unless there are ways you can automate or streamline the process. A good product management tool can help here.

2. Go to your users and ask for feedback

Instead of expecting users to come to you with their feedback, find ways to go to them, either on a 1:1 basis or by adding feedback channels where they already spend time. These might include:

There are likely to be multiple places where you can capture customer feedback. Maybe you have more formal mechanisms like monthly catchup calls, usability sessions or maybe a user group meeting. Whatever avenues you use, think about how you can make it easy for users to give you feedback. Can they fill in a form, send an email or complete a survey? Can you open up an “office hours” type session where users can drop in to tell you what they think?

Consider the best format for your user feedback – should it be verbal, written, audio, video or image based? Combine the right format and channel with the relevant user interaction, and you’re making it much easier, and therefore much more likely, for users to tell you what they think.

3. Keep it all together for better analysis and segmentation

Keeping all your feedback in a single place makes it easier to analyze and identify themes. It helps to identify connections, prevalence, frequency and segment your feedback in a way that makes it useful. Consider collecting attributes related to your feedback such as persona, market segment, country, industry, etc. This will allow you to segment your feedback and identify themes that help you to solve the right problems for the right market, and improve your product/market fit.

4. Keep the conversation going

The best way to reduce conflict in your organization is to share what you’ve learned from feedback with the rest of the team. Whether you’re talking to developers, marketers, sales, success, the executive team, support or anyone else, using the words of your customers as context to your discussions adds weight to your perspective and helps to get buy-in. You may want to use verbatim comments from users in presentations, or have statistics on how many customers requested your proposed change. 

Make sure you keep the conversation going with your customers too. Share your roadmap so that they can see you’re acting on their suggestions, and ensure they’re included in invitations for usability testing or beta testing, especially if it relates to a change they’ve asked for. Maybe give them a name check in feature announcements if they’ve been publicly vocal about their request, and it’s definitely worth notifying anyone who’s requested a feature when it’s released. 

Customer Feedback is everything

So, in product management, customer feedback is everything. If we don’t have feedback, and don’t know how to use it, we’re shooting blind. Feedback is useful in every part of the process! Don’t just think about it being the way we learn, incorporate feedback loops into the way you build by testing along the way and as a way of measuring success, too.  

It helps us to define the “What” – what are we going to build, change or remove. It helps us to understand our users’ pain points and problems, so we know where the high-value opportunities lie.

It explains the “Why” – the context around the “What”, helping us to create the best possible solution, so that we can delight our users and make it easy for them to get what they need.

It encourages iteration. Rather than delivering a solution and moving on, feedback encourages us to look again and be positive we’ve solved the problem. If we’re still seeing feedback that the problem exists, we know we still have work to do and an opportunity to add more value is still available to us. This in turn helps us to maximize success for our customers and our own organization.

And of course, collecting, understanding, and acting on user feedback encourages engagement with our customers. It’s a win:win situation – our customers get the best products, and we are as successful as we can be.

The post How Do You Introduce a Product Feedback Process? appeared first on ProdPad.

Customer Feedback mechanisms help us introduce psychological safety

Product managers need to be able to say no, and that’s not always done with tact. But how does the PM know that their stakeholder’s idea is unpopular? How do they push back with such confidence? Maybe the PM doesn’t care about anyone’s feelings (I’m sure we’ve known people like that), or maybe they can be confident because they have feedback that supports their case.

If you’re in conflict with a stakeholder about their idea, it’s easier and less confrontational to say “feedback indicates that this isn’t something our market would benefit from”. The stakeholder isn’t wrong, the market isn’t ready for their idea. It’s the feedback’s fault. Customer feedback helps to manage conflict here, and introduces psychological safety into the discussion, so we’re more likely to stay engaged and work productively with stakeholders.

We regularly get feature requests from customer-facing colleagues – sales, operations, support, success – people who act as a proxy for an individual customer (or sometimes many) and are under pressure from them. 

Spongebob is burning the feature request because he’s fed up with having to deal with this stuff. He can’t possibly act on every request he gets, and it’s easier to just burn the request than deal with it. Not only that, he knows that this isn’t going to progress, and he just can’t work out how to say so (he’s not as tactless as our Doberman dog meme). What if he had a mechanism so that the request could be used to help validate decisions, and was useful?

Just like the last meme, this situation would be easier to handle if Spongebob had a way to manage the customer feedback that lands on his desk. There would be no secrets and he’d be able to use it to make his job less confrontational and stressful.

Feedback helps us to build the right thing, and resonate with our market

We need our products to be successful so that the organization achieves its goals and, frankly, we all continue to keep our jobs. 

How do we avoid failure, or at least minimize the risk of failure? And if a product fails, and we need to change course and pivot, how do we reduce the likelihood of it failing again? The answer is to use our feedback wisely.

A launch based on an understanding of user needs is more likely to be successful. This understanding is twofold – it’s partly about understanding the user but it’s also about how we launch the product. How do we ensure our user base has the information it needs to begin using the product? How do we communicate in a way that resonates? Understanding our users means that we can build the right thing, but also that we can relate to them and help them be aware that a solution exists.

User testing is a great source of feedback

Most of us will have seen this meme or variations of it. It signifies the difference between UI and UX, how design can make something pretty, but how our users will bend what we give them to their way of working. 

In reality, great designers are constantly seeking feedback from their users in order to design a user experience that works well, in addition to being aesthetically pleasing. We tend to think of customer feedback as being asynchronous, but that isn’t necessarily the case.

Let’s think about the different methods we can use to get feedback. We often think of feedback as coming in the form of feature requests by email, or in a support ticket. But what about usability testing? Beta testing? There are a number of different ways to collect feedback. When a designer puts a prototype in front of a user, or even observes them using a real product, they’re collecting feedback that can be used to iterate on the design and make it more usable, more delightful. Hopefully, that rut in the grass doesn’t appear.

Be thoughtful in how customer feedback is used

I expect many of us have seen this one. Like the last example, this is about design, and it illustrates the point that feedback isn’t a license to just do whatever the user asks for. Just because we get lots of feedback telling us to jump doesn’t mean we should ask “how high?”.

Understanding feedback is as important as collecting it. We need to ask why again, and again and again, until we really understand the user’s pain point. 

I often quote the example of my 75-year-old Dad, who once rang to tell me he needed to write a macro in Excel. Rather than teach him how to do it (which would have needed some learning on my part!), I asked why. He told me he needed to make sure a specific field in his spreadsheet was filled in a certain way. I continued to ask why until I thoroughly understood the context (what spreadsheet was it, who was it for, why did they need it, what problem was it solving for them). We settled on a different solution (we just formatted the field to pick from a list of values in the end).
This solution was much simpler to implement, solved the real problem, and didn’t involve the two of us learning how to write code. He was blown away with its simplicity, and I gained valuable daughter points. 

Feedback can come in the form of product analytics

In this example, think of user feedback as an expression of frustration, and an indication that there is a problem to be solved. It’s letting us know there is an opportunity to help our users, and in a business environment, to make money. In a less commercial environment, it may be an opportunity to introduce efficiency. Without access to users and a feedback loop in place, we would create complex solutions that add to frustration rather than solve problems.

Feedback doesn’t always come in the form of customer requests or individual user comments. The dictionary definition of feedback is “advice, criticism or information about how good or useful something or somebody’s work is”. I’d argue that the value of feedback is not just its content, but also the volume, prevalence, or frequency associated with it. I might have 100 pieces of feedback relating to a problem experienced by my users, for example, but if it was received over five years, from 15,000 users, it might not be that big a problem. 

Data and analytics and an understanding of how to interpret them are important here. If we aren’t able to collect information from users on usage in the real world, how can we know what works and what doesn’t? User feedback comes in the form of real usage data – if our users like our product and find it useful, that will feed back to us in the form of high adoption rates. If it’s not working for some reason, we’ll see that in the data.

Reduce the friction to get more feedback

This one makes me laugh a lot. It’s a little bit like the phrase “If we build it, they will come” – but of course, users won’t react to a new feature if they don’t know about it – it’s why we have marketing. It’s the same with customer feedback – if we don’t provide an easy way for users to tell us what they think, they probably won’t bother. 

They’re lots of fun, but these memes are also really useful because they genuinely showcase the value of a good customer feedback mechanism. They show us that user feedback loops can help us introduce psychological safety, that feedback helps us to build the right thing, and to ensure we resonate with the market. They also show how important it is to consider all possible forms of feedback and remind us that we need to consider carefully how we use it.  If we don’t have feedback and don’t know how to use it, we’re shooting blind.

The post Customer Feedback: The secret sauce in your product process appeared first on ProdPad.

Remember, your roadmap should be easily understandable and digestible to anyone who looks at it. 

Need some help to get working on a roadmap? See what ProdPad can do for you.

The post Product Roadmap Presentation – How Detailed Do You Go? appeared first on ProdPad.

As a product manager, your job is to make sure the final product meets the needs of your customers. You can only do that if you’re capturing customer needs and communicating them as best you can!

What is a user story?

Put simply, a user story captures what the user needs your product to do and why.

The “story” part is quite short. In fact, the typical story only includes the three elements I just mentioned: the user (or customer persona), their need, and a purpose. The end!

It’s a way of writing product specs that explains the reason for a request, rather than describing a solution to that request.

For example, “As a customer service agent, I need to record notes after a call, so that my other teammates have full context about a complaint and we can keep the customer happy.” 

This user story doesn’t suggest a text box in a CRM or any other UI solution around recording notes. Instead, the story communicates the need for sharing inter-team knowledge in order to boost customer success and reduce churn. 

If you need, take a moment to learn more about user stories in general. When it comes to writing great ones, of course it’s important to make sure you’re wording everything in a way the developers can understand.

But more than that, writing great user stories is about the research, thought process, and structure you apply into them.

5 tips for writing user stories

1. Use one specific story format.

Pick a fill-in-the-blank format for your user stories. (That’s “Mad Libs” style for anyone who gets the reference!)

Something simple and easy is usually all you need. Here’s an example that works for most products:

Using a format is helpful for a couple reasons.

The first is collaboration. The whole team should be able to contribute. The simple fill-in-the-blank design ensures user stories can be written by anyone on the team.

The second is comprehension. Formats help ensure that all user stories can be read and understood by anyone on the team. The key points are captured and structured in a way that makes sense.

If the product manager or developer needs more context, they can directly follow up with whoever discovered or wrote the user story.

Of course, such formats only work if everyone is filling them out in a smart, effective way! Our next tip helps with that.

2. Focus on the goal, rather than the need or want

Whatever comes after “so that” or “in order to” is the more important part of a user story. 

I can’t stress enough how important it is to define the goal. This is the ultimate desired outcome. Focusing on the goal, rather than the need or want, has a two-fold benefit.

In the writing process, it forces the person who’s writing the spec to actually articulate what they’re trying to achieve. If they can’t pin it down themselves, how is anyone down the line going to understand?

Perhaps most importantly, focusing on the outcome creates a space for developers to think creatively about how to reach that goal. With full knowledge of the product’s technology and its purpose, dev teams can devise cool solutions that satisfy wants and needs in ways that customers and other team members (including you!) won’t think of.

On that note, you don’t want to send user stories that are prescriptive, e.g. “I want this button.”

Allowing for interpretation and creativity is key. It’s far better to pull in the expertise of other people on the team than to narrowly specify something and hope it’s the right solution.

3. Spend some time with Jobs-to-be-Done

If you’re having trouble defining the goal, try looking at your user story through the lens of another common framework: Jobs-to-be-Done.

Identify the jobs that someone hires your tool to do. What is it that they want your tool to do for them?

This approach helps you think wider about how your tool is used and what might be your user’s goal — or maybe there are multiple goals! 

It also illuminates what your competitive space actually is, both on and off the market. For example, if yours is a tool for task organization, maybe you think your “competitor” is a spreadsheet but it’s actually a post-it note. That’s a totally different way of getting the job done! So, this can transform how you conceptualize your tool and inform how you create new competitive solutions.

4. Make sure your personas are based on behavior, not demographics

Behaviors should inform the needs, wants, and goals that you’re writing about in user stories. That’s why the very first element in the story — the persona — is fundamental to a successful spec!

It’s important to create personas based on user behavior, not customer demographics. Stick to details about how this person uses your tool and interacts with your UI. This ensures that the personas’ needs are relevant to your product.

And don’t forget to update these personas from time to time! As your product evolves, so does user behavior.

5. Go back to the source

Good user stories begin with good research and discovery. That means talking to actual users, as well as collecting feedback from the rest of the company.

Make sure you’re uncovering real problems and real needs, and make sure you’re understanding and representing them correctly. The risks are that you either legitimize and prioritize needs that aren’t actually important, or you overlook spots where new solutions could have a valuable impact on your product and company objectives.

Close listening to customers also helps you develop acceptance criteria, an important part of any user story. The team uses acceptance criteria to recognize when the job is actually done and fulfilling the customer’s needs.

The post Remember These 5 Quick Wins for Writing User Stories appeared first on ProdPad.

The job of a product manager is to discover market problems, and then define what should be built within their product to solve these problems. Their goal is to improve outcomes for the people who use their product. They must identify those ideas that should provide value for the business, and then help the rest of the business to turn those ideas into reality. 

Sounds simple enough, right? The problem is that there will always be a wide range of opportunities to pursue, and each one of them will take time, money and effort. So product managers must use their skills, knowledge and the tools at their disposal to help their organization make good decisions about what to do next.

Product managers must ask the questions needed in order to make tough business decisions about new product features or enhancements. Marty Cagan, product management guru and partner at Silicon Valley Product Group, explains that a product manager should always consider value, usability, feasibility and business viability. This means that they should look at the following when deciding what to work on:

• Will this provide value to our customers?
• Is this change usable?
• Can we deliver it – is it feasible?
• Can our business support this change – is it viable?

The answers to these questions will help the business to decide where to invest in order to get the best return on investment.

What does a Product Manager do?

Day-to-day, a product manager communicates with different people, both inside and outside their organization, either to learn, or to share their learning. This means that it’s important for them to understand the organization’s different business functions. This is because they must facilitate and broker discussions between technical and business stakeholders. Product managers also need to have conversations with customers and end users of their product, and to be able to communicate at both a strategic and a detailed level, depending on the conversation. Finally, it’s important for product managers to document what they learn as they go, so they can easily use what they’ve learned to make the best decisions.

In general, a product manager is responsible for:

• Carrying out research on market needs by collecting feedback, reviewing data and examining the market landscape
• Discovering problems to be solved, based on the research they’ve carried out
• Identifying the most valuable opportunities for the business – which bets are most likely to pay off?
• Working with their product team to identify potential solutions to those valuable opportunities
• Defining what success looks like. For example, what outcomes should be expected, and how can they be measured to assess whether they’ve been achieved
• Experimenting to determine the most successful solution
• Measuring success and determining next steps

A product manager’s goal is to provide the best outcomes for customers, with the smallest possible investment. 

Product Manager’s day-to-day job

It sounds like a lot, doesn’t it! But there are some key tasks that product managers carry out on a daily basis:

• Collect feedback on market needs (in person, on zoom, via surveys or via customer-facing team mates)
• Define the product strategy based on the needs of the market and business objectives – this is known as creating the product roadmap
• Communicate the strategy to others, and seek to understand how it could be improved
• Break down the strategy into executable pieces
• Work with design and development teams to create product specifications
• Collaborate with customer-facing functions to help with their go-to-market activities

Product Management vs Project Management

A product manager’s responsibility is discovery rather than delivery. The skills that deliver a successful project – resource management, capacity planning, budgeting – are very different from those needed to uncover opportunities. Product management is not project management – that’s why we also say that a roadmap is not a release plan. In short, a Product Manager defines “what” and “why”, while a project manager defines “when”, “how” and “who”.

What makes a Great Product Manager?

A great product manager brings together a diverse, cross-functional team of people so that they solve a problem. They’re entrepreneurial and know how to to break big problems down. And they can see how to provide value in a way that reduces business risk. They use tools that help them to gain insights and make good decisions. Above all, they’re data driven and are excellent communicators.

If you’re looking for ways to ensure you stay up to date with Product Management best practice within your work start a trial now to see how ProdPad can help you.

The post What is a Product Manager? appeared first on ProdPad.