A recent study found that 52% of U.S. workers are “worried” about AI impacting their job, while only 29% are “excited” about AI.

Where are you on this spectrum? Where do you want to be?

The best way to navigate this landscape is to try the technology, which will help you identify opportunities to leverage it.

Just commit 2 minutes to start. Right now, open ChatGPT and enter: “Draft a concise, professional email asking for a meeting about [any topic].” Try it and see what it does!

Example: In less than a minute, ChatGPT drafted an email and adjusted it based on my feedback

The more context you provide, the better the output will be

Some practical use cases for AI tools:

Improve your writing

• Ask a GenAI (Generative AI) tool to improve something you’ve already written, such as to more clearly communicate the key points or to shorten the length
• Example prompt: “Make this email more concise and professional”
  Tools: ChatGPT, Claude

Prototype an idea

• Whether it’s something related to your job or just an idea you’ve had, you can get it visualized in just a few minutes
• Example prompt: “Create a landing page for a task management SaaS product”
  Tools: V0, Bolt, Lovable, Tempo

Do research

• Ask a GenAI tool to provide data, a list, or a summary about something you’re working on
• Example prompt: “List the top 10 software technology companies in the U.S. based on revenue, and include their top products”
  This prompt could be more targeted by including a particular industry, type of solution, or other aspect
  Tools: ChatGPT, Claude

Find potential customers

• You can generate lists of LinkedIn profiles of your target customer based on several criteria, such as job title, industry, and location
  Tools: Clay, Waalaxy

Set up an automation

• If you can imagine it, you might be able to automate it
• Simple example: When X event happens, send an email to someone or add a row of data to a spreadsheet
  Tools: Make, n8n, Gumloop, Lindy

The tools listed above are only a subset of what’s available and I’m not recommending any specific tool over any other

Example: In under 2 minutes, V0 created a landing page

Note: I sped up the middle of the recording while code was being generated
(the original length was under 2 minutes)

Once you’ve created a prototype (e.g., landing page or web app),
you can prompt the AI tool to make adjustments and refine the solution

Many AI-powered tools have a free account option to try the capabilities and determine value, and some allow for a generous amount of free usage that you may never surpass.

There are some great resources to learn more about the current state of AI and where things are heading, including “2024: The State of Generative AI in the Enterprise” (from Menlo Ventures), this list of AI tools (from a16z’s Consumer Team), and Allie Miller’s newsletter.

If you’re in product management, you may find it useful to subscribe to the GenAI PM newsletter, dig into Tal Raviv’s tactical content about leveraging AI, or take Colin Matthews’ online course. Or you can just watch a few short videos on YouTube to see demos of tools you want to learn how to use well.

While I don’t believe we’re facing a complete replacement of certain roles from humans to machines, we’re already seeing a drop in certain roles that AI has reduced the need for (e.g., customer support, research), and there’s an opportunity to not only catch up but to excel in this developing landscape.

Pick one AI tool from the links above and try it today. Experiment, iterate, and see how it fits into your workflow — you’ll be ahead of the curve before you know it!

If you’re not familiar with the term Voice of the Customer, it’s a collection of systems and processes that can be used by your company to stay in tune with what customers are thinking, providing the team with insights that can be applied to product development plans, process improvements, and other types of changes.

Having the Voice of the Customer represented well in a company can mean the difference between solving the right problems vs. going in the wrong direction, and ultimately succeeding or failing. When things go in a negative direction here, outcomes could include a poor customer experience, increased churn, and lack of revenue growth, among other things.

To do Voice of the Customer well, a company needs to be coordinated and proactive.

• Coordinated – Multiple departments should work together on collecting, analyzing, and actioning the data. Any function in a company that’s customer-facing or can leverage customer insights should be involved, such as Customer Success, Customer Support, Marketing, Product, and Sales. The value extends well beyond product development, and you can help a company capture that value by incorporating these kinds of functions.

• Proactive – You’ll end up with the best quality of insights by incorporating a variety of sources beyond only reviewing a passive communication channel like customer support tickets. This requires an investment of time and is worth it.

Depending on your company’s business model (e.g., B2B, B2C, B2B2C) and target market segments (e.g., SMB, Enterprise), some methods of getting customer insights may not make sense for the program.

Directly from customers / the market:

• Listen in on team member calls with customers & prospects (e.g., Customer Success, Customer Support, Partnerships / Business Development, Sales)
  •  Only 1 person from a team that’s not facilitating a call needs to join, such as 1 Product team member joining a call that the Sales team is doing
    • Things might evolve into team member pairings between departments, such as Product Manager A collaborating with Salesperson A, Product Manager B collaborating with Customer Success Manager B, etc — and insights can be shared back among each team
      
• Review customer support tickets
  • Your company’s Support team might already have a way to tag or categorize tickets to help identify common issues
    
• Analyze survey results (e.g., NPS, CSAT — or do a one-off survey)
  • Some of the most useful data from standardized surveys like NPS (Net Promoter Score) is in the freeform text answers that customers can optionally submit
    
• Facilitate calls with customers for team research initiatives (e.g., product discovery, customer advisory council)
  • As a Product person, you may already be doing things like this, but make sure you loop in other departments and contribute insights to the centralized Voice of the Customer program
    
• Read company/product review sites (e.g., Capterra, G2, App/Play Store)

Among team members within a company:

• Schedule recurring time on the calendar and include the whole company as optional invitees (e.g., a bi-weekly “Product Workshop” or “Office Hours”)
  • I’ve run these from a Product perspective, but it could be facilitated by other departments/functions. A key is sharing useful info and inviting feedback, and it can naturally open up lines of communication and build more cross-functional involvement over time. I’ve written a bit more about this here.
    
• Periodically meet with members of other departments to hear about trends they’ve noticed and what they believe deserves attention (e.g., Customer Success, Customer Support, Sales)
  
• Review notes (or watch / listen to recordings) from team member calls with customers & prospects
  • Keeping notes and recordings might already be a process among your team, and like many other situations, you’ll likely find the most success by providing a reason (focusing on the expected value) why people should share such things with you

Notes should be taken during any meeting, and consider recording meetings if there’s a larger audience that’d benefit from reviewing async.

If you listen in on a call or watch a recording, take notes and share them with the facilitator of the call afterwards. In addition to being useful for your function, I’ve found that demonstrating good note taking, and consistently sharing, can encourage others to loop you in more regarding customer insights they come across or opportunities to participate.

You’ll also benefit from using tools to document what customers say, run surveys, or manage other activities related to your Voice of the Customer program. You likely already have some relevant tools (even as simple as Google Docs), and it may help to incorporate additional ones. Don’t let a lack of tools keep you from getting something off the ground though, as you can work on optimizing over time.

Be mindful of potential pitfalls:

• Asking too much of customers, such as frequent surveys or invitations to have calls. For example, systems could be set up to automatically ping customers (e.g., NPS or CSAT surveys), possibly on a recurring basis, so be mindful of who is targeted by such things and how often before trying something new that’s customer-facing.

• Collecting a lot of data and not doing much with it. If you’re going to invest in a Voice of the Customer program — while getting buy-in and participation across the company, you’d better follow through and extract the value that it can provide. Starting small is fine, and make sure you follow through so you can build on it.
  • Start small by adding insights in a Google Doc and sharing the doc with teammates. When the process picks up steam, you can make the doc look better (e.g., add sections with a table of contents) or move the content to a different tool that might be preferred for centralized documentation.
    
• Not closing the loop. If you work with members of your company to collect, analyze, and/or action customer insights, sharing updates about what you’ve done or plan to do will go a long way in supporting a repeatable process for everyone.

It’s great if you currently listen to customer feedback, and if you use what you learn to inform priorities and plans. This is valuable and should continue. If you encompass that approach into a Voice of the Customer program — while also doing additional things such as what’s mentioned in this blog post, then you can likely create more value — based on a higher volume and greater depth of customer insights that can potentially result.

If you believe this is worth doing, you’ll need to determine who is best to organize it in your company, and who should be responsible for acting on the findings.

In my view, it doesn’t matter which department or function owns the program, as long as someone is the clear owner. A natural fit could be ownership by Product Management, Product Operations, Product Marketing, Customer Success, COO, or something along these lines.

Once team member involvement is coordinated and people know the process to follow, the program can run async — aside from meetings designed to collect, analyze, or share customer insights. The person who owns the program should periodically check on how things are going and offer help to clear blockers or implement improvements.

When things go in a positive direction here, outcomes could include a better customer experience, increased customer loyalty, more revenue, and even higher employee retention if done in as cross-functional a way as I advocate for. Doesn’t now sound like a good time to get Voice of the Customer started at your company?

Thanks to Mik Pozin for providing early feedback on this post

For a long time, everyone seemed to use “MVP” (Minimum Viable Product) to refer to the first version of what they’ll release as a product. “MVP” has been used in books about product management and startups, blog posts, etc. I still hear “MVP” a fair amount.

A couple of years ago, I started to hear “MLP” (Minimum Lovable Product) used by some people instead of “MVP.”

I personally like “MLP” more than “MVP” because a “lovable” product sounds more appealing and valuable than a “viable” product, but if you asked 10 people to define what an “MVP” or “MLP” is intended to represent, you’d probably hear several different answers. Most of the answers might generally point in the same direction, but there wouldn’t be alignment in the definition.

Now think about how important it is for a team within a company to be aligned on what they’re setting out to do. Whenever “MVP” or “MLP” is said within that team or company, each person hearing it might have a different mindset about that first release.

Is the first release meant to test a hypothesis? Is it meant to help establish a new revenue stream? Is it meant to make a specific customer happy (in the enterprise world)?

Should the first release look perfectly polished? Should it be adequately polished? Is it okay to be somewhat ugly (as long as it’s usable)?

Different people think about these things differently, even within the same team/company. This is the problem with using “MVP” or “MLP.”

Instead, I use “V1” (Version 1) to represent what will be in a first release, and I accompany that with a story and artifacts (e.g., goals, flow diagram, wireframes, a design) to provide context and details. “V1” simply means the first version, while the purpose of that first version — the goals, etc — vary from one situation to another.

The same person (product manager) could take a different approach for a first release in different situations. For example:

• Is the first release going to be a limited rollout? A full rollout? Will it only be seen by existing users? New users? Both?
• Are the users who will see the first release in close communication with the team/company? Or is the intention to have them be on their own?
• Can the first release include a manual process that’s not a seamless solution or fully automated (e.g., using Google Forms)? Or does it need to be seamless / automated?

There’s no one size fits all in product management. Use an approach that relies on YOUR definition, not someone else’s assumption. “V1” can help you do this.

The best email newsletters for this purpose are ones that include summaries or snippets of each story so that you often don’t need to click for the full story, since you’ve learned enough from the text in the email. If you want more details, you can click to get the full story.

Here’s my current list of email newsletters:

Launch Ticker – Tech news

• Free Version – Delivered once per week
• Paid Version ($10/month or $100/year) – Delivered twice daily on weekdays and once daily on weekends

The Hustle – Focused on tech and business

• Delivered once daily on weekdays
• Free

theSkimm – Covers general news, including U.S., world, and entertainment

• Delivered once daily on weekdays
• Free

CNN Five Things – The top 5 stories that a CNN editor decides to push on any given day

• Delivered once daily on weekdays
• Free

The Journal – A collection of tech, business, and human interest stories

• Delivered once per month

I’ve used this system for a couple of years now and it’s kept me informed in an efficient way.

I also occasionally use the Apple News app, but I get a lot of the same news in the emails.

I also receive new blog posts via email from several blogs for the same efficiency reasons mentioned above about newsletters. If a blog doesn’t provide an email subscription option but does provide an RSS feed, you can use Blogtrottr to send you emails with the new content that gets added to the RSS feed (i.e., new blog posts).

Do you receive a different email newsletter that you’d suggest others take a look at? Send me an email and I’ll check it out.

Since “strategy” can mean different things in different situations, here’s a definition of how I think about it related to product management:

Finding efficient ways to achieve the company’s goals through product solutions

Another way to think about it is:

Finding ways to maximize value at minimal cost

A good product strategy can give you a leg up in a race against the clock (or the competition), and it can increase the odds of your team and company being successful.

The maximize value part

This comes down to translating company/business objectives (including key metrics / KPIs) into a product plan that helps the company achieve its goals.

Product folks are tasked with helping their company achieve its goals while also helping customers (aka, users) achieve their goals, and while also keeping their team informed, efficient, and motivated to get it all done. (Project managers or other roles in an organization can also help a lot, but these roles don’t always exist.)

Sometimes, there’s a clear path for how product work can help the company achieve its goals, such as when an integration with a partner can propel a business strategy. Other times, the team needs to explore possible solutions to meet the company’s goals, which factors in:

• Customer needs discovery/analysis
• Team brainstorming (including exercises such as whiteboarding/sketching)
• Research/testing with customers

After this, solutions need to be designed, built, tested, and released.

After releasing something, it needs to be measured and potentially iterated on to build out further or to optimize.

I could write posts to cover each of these steps, but in a nutshell, this is what needs to be done in order to maximize value. Depending on timelines and resources, you might be able to skip some steps, or at least move through them faster, while still achieving the goals (and perhaps revisiting in the future for further improvement). In general, I’ve found that it’s more important to be practical with how you go about things than to try to follow a process according to every detail as it’s written in a book.

The minimal cost part

There can be several types of costs with product work, including:

• Dollar cost – You might need to pay for a technology or service to achieve a solution, or you might need to hire people. These are straight dollar costs.

• Time cost – It takes time from one or more team members to do anything, which can be equated to the dollars that the company spends employing those people for their time. For example, if the company spends $50 per hour on an employee, and if it’d take 10 hours for the employee to complete something, then the cost of having that employee do this work is 10 hours of time which you could equate to $500.

• Opportunity cost – This comes down to prioritization. In general terms, if you work on Option A now, then Option B might be postponed until Option A is done. The expected gains from Option B (which could be postponed) is an opportunity cost of Option A. For example, if a $10,000 gain is expected from Option A while a $5,000 gain is expected from Option B, then you might prioritize Option A over Option B. In this case, Option A brings an opportunity cost of $5,000 (i.e., expected gain from Option B), which is generally okay because it’s less than the expected gain from Option A (i.e., $10,000).

• Team dynamic cost – This can be harder to quantify than other costs. On a high level, if your team is happy, motivated, and efficient, they’ll be positioned to do well (assuming they’re working on the right things and helping the company succeed). The challenge is maintaining a positive environment for the teamwork, which includes communication, collaboration, celebrating wins, learning from issues, and making it clear that it’s ok to discuss struggles or suggestions for the benefit of everyone (doing sprint retrospectives is one way to facilitate this). Some situations bring more pressure than others, but always remember that you’re part of a team that comes to work every day to solve problems, so tap into that in a supportive and collaborative way.

An example of where to apply strategy

Do multiple current customers, prospective customers, current partners, or prospective partners have similar needs? If so, you might be able to leverage a new product capability that can provide value across a broad spectrum of users / entities. In other words, doing a single body of work that results in more than one win is a strategy that could be explored.

Things that can help think through strategic opportunities

1. Create a product plan (roadmap) looking ahead 12 to 18 months

• Break it down by quarters (e.g., Q3 2017, Q4 2017, Q1 2018, Q2 2018, Q3 2018, Q4 2018)
  
• You only need to think about high level items (i.e., a new product/app or major new capability of an existing product/app) for the periods that are between 6 and 18 months away
  
• Be more detailed with items for the periods up to 6 months away
  
• Keep in mind — and include an explicit note on the roadmap — that roadmaps change based on shifting priorities and new learnings (about customer needs, partnership opportunities, etc). You want the roadmap to be seen as directionally correct, but fluid based on the company’s shifting priorities (or significant shifts in what’s learned from the market, such as customers or competitors).

I’ve used a few different roadmap formats over the years and currently employ the following two for different purposes:

Template A:

(this is good for high-level discussions around significant high-level deliverables)

Template B:

(this is good for mid-level discussions that gets more detailed than Template A)

Template B also helps to facilitate update meetings with any stakeholders about progress, what’s been accomplished, if there are risks or dependencies, etc.

Beyond Template B would be a backlog that gets very granular (often tracked in software like Jira, Trello, or some other project/task management tool), which typically only needs to be reviewed with scrum team members (e.g., developers and QA).

(I’ll save for another post why it’s better to have a goal-based or theme-based roadmap than a feature-based roadmap.)

2. Meet with your company’s executive leadership team (e.g., CEO, CTO, the heads of Marketing / Sales / Business Development / Customer Experience)

The main goals are to:

• Recalibrate on business priorities
• Make sure that executives across the company understand what’s been happening with the product and what the vision and plans are for the future

At some companies, it’s easier said than done to get executives in a room together, so you might need to sell this kind of meeting in advance by setting expectations for what’s going to be covered and what the goals are (which should clearly sound beneficial to the company as a whole and also to each department)

Conclusion

Strategy is a skill that can be developed over time. The more you think about it, work through exercises, collaborate with others, and read about examples, the better you’ll get. Just always keep the main purpose in mind: finding efficient ways to achieve the company’s goals and finding ways to maximize value at minimal cost.

Examples

Success notifications:

One of my favorite little things is a checkmark that appears after you’ve successfully done something, such as adding an item to a list or updating a profile. I refer to this as a “success notification,” which come in many varieties.

• The text that accompanies the checkmark can say whatever is appropriate for the action that the user took (e.g., “Added” or “Updated!”)
• In some cases, it’s fine for the message / checkmark to automatically fade away after a second
• Bonus points if the user sees the checkmark draw itself (but this is of course more time consuming to implement)

Loading indicators:

Waiting for a page / screen / module to load can be frustrating for a user if it lasts more than a second, so having a nice loading indicator is an opportunity to prevent dissatisfaction. Any kind of indicator is better than nothing (e.g., a simple spinner), but some extra effort can make it a good experience.

Seeing the above isn’t so bad, right? It makes me think about the indicator, as opposed to the fact that the data on the screen hasn’t loaded yet.

Compare that to a very basic loading indicator:

And compare both of those to a complex (and very nice) example that’d take more time than most early-stage companies have for this kind of thing:

So where should you end up on this? How about a spinner, but a little more interesting than the most basic kind, such as:

It’s great to find ways to reduce loading times (such as by caching data, removing unnecessary data, or loading multiple things asynchronously), but loading time is a reality and you can prevent it from being an unpleasant one.

Error handling:

Plenty has been written about creative 404 pages, but error messages are another area that deserves attention.

I’ve seen error messages that aren’t clear what the problem is, aren’t helpful with how to resolve the problem, and don’t seem like they fit into the design of the application that they’re a part of. A little bit of descriptive text goes a long way, and a tiny bit of design attention is better than nothing.

Don’t overlook error messages as part of your user experience approach.

Planning

I like to have yearly, quarterly, and monthly plans when it comes to roadmapping.* These plans outline an approach to hit company goals while solving for user needs. Examples of company goals are increasing sales by X% or $Y, or reducing churn by Z%, within a set period of time.** A roadmap should be focused on achieving company goals while solving customer problems, but with some planning, you can likely also fit in some “little things” along the way.

I suggest doing advance planning for the little things just like you should be doing advance planning for the bigger things that are aimed at company goals. If you identify something that could be made nicer with a little thing, add it in your backlog or other type of planning documentation and prioritize it appropriately.

At any time, if something needs to get bumped from your plans, it should be the little things. With this approach, you’ll be focused on company goals and solving important customer problems, while also delivering value via the kinds of nice little things that are often missing from products to improve a user’s experience.

*I also build an idea of where things might be more than a year into the future, but that’s on a higher level with less detail because things are expected to change over time. Things also change within a quarter or even a month, but items on a roadmap within the next quarter are typically rearranged and not cancelled, while items more than a quarter out are more likely to be cancelled. So, have a vision for where things can be in the future, but don’t spend significant time on the detail.

**It’s important for any goal to have a target (i.e., a number to achieve), a deadline (i.e., how much time you have to achieve it), and a clear way to measure progress. Define success, measure it, learn from it, and report on it.

Sharing product information within your company is one of the most valuable things you can do as a product manager. Whether it’s your plans (roadmap), feedback you’ve heard from users, product usage data (analytics), or posing questions — getting what you’re doing and thinking in front of a cross-departmental audience will provide you with input that helps you make better decisions and will help align others with the goals you’re looking to achieve.

Spreading info can also help other people be more effective in their roles as they’ll be able to better prepare for upcoming changes. It can get them excited about the direction of the product, and it can make it known across your organization that you’re a person to bring questions or feedback to — opening up more lines of communication to help inform your thinking.

Hold a recurring meeting once per month that gets you in front of a cross-departmental audience.

Invite people not only from Product & Tech, but also Support, Sales, Training, and any other relevant group.

Create slides to walk the audience through:

• What’s been happening with the product (e.g., recap the last release, usage data)
• What’s coming up soon (e.g., the next release)
• Future thinking (e.g., distant roadmap possibilities)
• Research initiatives (e.g., what problems about your users or business you’ve identified recently and their impact, what solutions might be viable, what you plan to learn about soon)
• Competitive analysis (e.g., if you recently discovered a new competitor that you think would be valuable for others to know about, or if you want to highlight how a potential new feature could be a differentiator for your company’s solution vs. others)

Solicit feedback.

At the end, recap any next steps and actions.

While this might take you a few hours to prepare for each month, sharing information (ideally in an engaging way) is one of the most valuable things that can be done within a company, not only bringing info to others but also to you.

These sessions can also give people better insight into how you think and approach things as a product person, which is particularly valuable to stakeholders who you don’t work with on a regular basis. And it’s a way to take people on the journey of the product, showing where it’s been and where it’s heading, growing support and buy-in along the way.

Sync with certain people in advance of this meeting to prepare material:

• Ask co-workers in Support about common user pitfalls and analyze Support case trends with them.
• Ask co-workers in Sales and/or Business Development about common sticking points that prevent a deal from closing. (Or if your company is more Marketing-centric, sync with the Marketing team.)
• Ask the appropriate people about why users stop using your product (i.e., cancellations / churn).

You’d ideally be able to see quantitative data on these topics, in addition to having conversations about them. Depending on how much detail is made available to you, it could also be useful to speak with some of the users who these topics relate to so that you can dig deeper into the reasons behind what they said to your co-workers (i.e., learning why something happened, instead of only what happened).

The following is an example sequence of slides that you could use or adapt:

1. Intro / purpose of the meeting (state a goal of sharing info and discussing possible solutions to problems)
2. Recap of last release
3. Plan for next release
4. Insight / question #1 (takeaways from recent research you did, a trend that you think is worth raising awareness for and getting feedback on, or some other topic you’d like to increase visibility on)
5. Insight / question #2
6. Questions / feedback (while you should welcome questions or feedback throughout the meeting, dedicate a couple of minutes at the end for anything not already covered)

Tips:

• Don’t feel like you need to do everything listed above from the start
  • You can start simple with a small audience and short list of topics to get feedback and adapt for the next session, gradually inviting more people.
  • The most important thing is to get started with something, and be open with participants about how you want them to get value out of it and that you welcome their feedback. Adjust the format over time to find what works best.
  • Aim for a 50-minute meeting. If you find that 50 minutes isn’t enough, trim some content for the next time so that you can get it done in 50 minutes. If you engage the participants (e.g., by asking some to help prepare material in advance, and by inviting questions/feedback during), this will feel like a short meeting packed with insights and takeaways for everyone.

• Frame the meeting in the right way
  • It’s not meant to be a collaborative prioritization session. Some open discussion among attendees is great, but it’s not a debate on what to work on.
  • You’re sharing information and believe that everyone benefits from hearing insights, both from you and others.

In general, respond quickly to whatever comes your way.

Even if you don’t have an answer that someone is hoping for (e.g., if your answer is that it’s going to be a while longer until their concern is addressed in the product), getting back to people in a timely manner gives them confidence to reach out to you again in the future, which can provide you with valuable intel.

In some cases you might pass someone’s question to someone else who is better suited to answer it, which is fine. Whether you or someone else answers it, you helped get the answer.

Recap

Communication is a two-way street. When you share information with others, they’re more likely to share information with you.

Having a steady flow of communication with a group of people from across your organization enables you to test ideas sooner, hear feedback sooner, and make ideas better — resulting in better product decisions and benefits for both users and the business.

Overall, communication can be a big factor in a product manager’s success, both with a product’s success and also the product manager’s career. Seize the opportunity to spread information and to learn from others, and position yourself as a go-to person in your company.

[Note: This post didn’t touch on external communication, such as with users, partners, or vendors, which is worthy of its own writeup.]

• It’s a quicker way to get your ideas into a form that you can look at and tweak.
• You can easily work through different variations by erasing or crossing something out, or flipping over the paper and starting again.
• It enables you to see an entire user flow in one view to visualize everything working together before making more detailed wireframes of each screen.
• It’s the fastest way to get feedback from a co-worker, which could result in a quick iteration or scrapping the whole thing and starting over.

By the time you’re ready to digitize what you’ve done on paper, you will have thought through the core goal(s) that you were trying to accomplish and worked through issues that you discovered along the way. Then, you can focus on any final adjustments once its digitized before handing it off to the next person in the development process.

Example

I came up with a ‘question of the day’ app for a simple example to use here. Depending on which out of the multiple choice answers the user selects, they’d see a different result. Here’s how I sketched it on paper:

It’s sloppy, but it’s a sketch (and I also have sloppy handwriting). Remember, the goal is to quickly reach a point where you can rethink the idea, or to get feedback from others, resulting in a better version.

When I was in the middle of the above sketch, I thought it’d be good to include a “change your answer” option, so I added one at the bottom right of each answer screen. Clicking on this would send the user back to the question so they could choose a different answer. I didn’t need to resize anything to fit this in — I just added it in the corner, and it’d look better in the next version of the wireframe.

When I finished the sketch, I thought it’d be good to show what other people had selected as their answers, similar to poll results. I couldn’t fit that into the answer screens that I had sketched, so I added a representation of it at the bottom right of the paper (and I would explain this to whoever I shared the sketch with). It could turn out that the poll result feature doesn’t make sense to include, or at least not in the MVP, so it could have been scrapped anyway. As long as it was sketched in some form, it was ready for a discussion or a decision.

Depending on who you work with and what they do in their job function (i.e., some designers and product managers handle different things and have different processes), you may find that all you need to do is deliver a sketch and have someone else run with it. Or you may be the person who receives a sketch and needs to make it better. Whatever the case, I’ve found that step 1 being on paper gets you there in a better way.

If you get more than a small volume of customer support cases, it may be worth a focused effort to improve the following two metrics:

• Number (or frequency) of support cases
• Average time spent processing each support case

Less issues + quicker resolutions = more happy users + more efficient employees. This is a path to better business results.

All of the things mentioned in the beginning of this post (user acquisition, etc) are important — typically more important than optimizing customer support — but when time spent on handling support takes a significant bite out of time spent on growing user base, building product, or working on any other key function of a company, it may be time to figure out how you can make an improvement.

While you may use multiple customer support channels, including email, live chat, messages via social media, and/or phone calls, I’ll keep this post focused on email for the sake of simplicity, and some things written about email can be applied to other channels. You may also find that some parts of what I describe apply more to your company than others.

Step 1 – Track the number of support cases that you get. If you use an app such as Zendesk, UserVoice, or Desk.com, it may include analytics that will show how many cases you get during set time periods (e.g., monthly). If you do support via regular email and not an app, it’s fairly straightforward to see the number of emails that come in (and you can create a “Support” filter if you use the email account for more than only support).

Ways to potentially reduce the number of cases:

• Create (or expand) an FAQ / Knowledge Base on your website – This is a great resource for users who have questions because a) they can get answers faster than waiting for an email response from you and b) you save time by needing to answer less questions. The material should include step-by-step instructions (and screenshots) where applicable, and be sure to keep it up-to-date. Consider using an app like Zendesk, UserVoice, Desk.com, or Helpjuice to provide some automation.
• Add more guidance in your app’s user interface – Small changes like adding tooltips, more descriptive copy for how something works, or arrows/text for the next suggested action that the user should take can reduce confusion and prevent questions from arising. Be mindful that it can be a delicate balance to keep clutter to a minimum in a UI while also keeping things informative enough. I’m a big fan of tooltips and there are many different types.

Seeing a reduction in support cases isn’t necessarily the best way to measure success because you’ll hopefully be gaining new users as time goes on, so you’ll measure success by seeing a reduction in support cases per user or per event.

• Measuring by users – Getting 100 support cases from a user base of 5,000 over whatever period of time (a support rate of 1 case per 50 users) is not better than getting 500 support cases from a user base of 100,000 (1 case per 250 users). The example with 500 cases is a substantially better (lower) frequency that will allow you to more effectively control support costs over time.

• Measuring by events – An event can be anything from an account registration to a sales transaction to a download. Identify the primary source(s) of support cases that you get (you’ll know this based on the subject matter of the cases) and then make adjustments to improve on the problem source(s). For example, if a download process is a big problem source, you’ll see users asking about it and can document how many cases arise per download event (or per attempted download if users are having trouble completing the download process, which would mean you’d measure the number of cases against the number of sales that are supposed to lead to a download). Based on this, you’ll be able to target improvements to the problem source and then track what will potentially be an improved (lower) frequency of support cases.

Step 2 – Get a sense of how long it takes to resolve each case. The time needed for each case starts when you open the support email and ends when the user’s issue has been resolved. If it takes multiple emails to resolve a case, add up the time for processing each of the emails. I suggest tracking 20 cases and using the average time between them as your benchmark to improve upon.

Ways to more quickly resolve cases:

• Have a collection of answers to common questions (such as in an FAQ / Knowledge Base) and copy and paste the relevant material into support emails. Depending on how your page with the help material is set up, you may be able to quickly find the relevant material by doing keyword searches via the keyboard shortcut Ctrl+F on a PC or Command+F on a Mac. Another option is to include a link in the email to where the user can find the relevant material on the FAQ / Knowledge Base, which has the benefit of introducing the user to a resource where they can find other helpful information, but also the drawback of requiring the user to go through another step to get their answer. I suggest copying and pasting short answers and linking to a resource for longer answers.

• Build a search feature in an admin panel (that only company staff can access) where you can search for information about particular users or transactions to quickly see details that can help you resolve a case. This would potentially save you from needing to have extra correspondence with users where you’d need to ask them for the same details that you could get from a quick search. For example, by searching for a user’s name, email address, transaction number, or other unique identifier, depending on what your system logs about users and transactions you could see things like the user’s device type, operating system, browser, purchase history, last login, IP address, additional email addresses registered on the account, and anything else that you find relevant to resolving support cases (as long as it gets logged).

Example of a search feature in an admin panel:

If it helps to know what browser someone was using when they experienced an issue, you’d know from a quick search without needing to ask them. If a user emails you from an address than you don’t have on file, you could search for their name and potentially find their account. Figure out what’s most important to know in order to resolve issues and create a way to pull up that info as needed.

Two important factors for creating happiness via customer support:

• Response time makes a big difference for customers. Many companies take 24 hours or longer to respond to an email, while the elite respond within a couple of hours. The faster you respond to (and resolve) someone’s issue, the more likely they’ll become a happy customer.

• Always include pleasantries in emails, such as “Hi,” “I can certainly help you resolve this issue,” “Please reply to this email if you have any additional questions,” and put your first name at the end. This shows that you’re human and that you understand people’s concerns, as opposed to letting someone think that you don’t care much about a user’s experience with your brand. The ‘human approach’ can also help you disarm an angry customer to the point where you can have a constructive exchange of information to more quickly resolve their issue. Angry customers make great evangelists when you turn their poor experience into a good one.

Providing a good support experience can help transform customers into loyal customers who will continue to use your product, tell others about it, and even provide you with a testimonial that you can use in your company’s marketing materials. Don’t overlook support as a way to help build your business.

This post was based on my experience handling thousands of customer support cases and using various tools to make the process more efficient. I didn’t include some details due to length concerns. Email me if you have questions.

• An ease of adding content into your items list for future consumption: you can save items to Pocket via email, a bookmarklet, and hundreds of apps
• The ability to use the app on many devices, including smartphones, tablets, computers, and even some e-readers (they’ve integrated with Kobo)

I point this attention to outside the app because the consumption experience and sharing capabilities inside the app are pretty good. There are always opportunities for tweaks and optimizations, but some higher impact changes can potentially be made in the areas of discovery and sharing when users are outside the app. I think the Pocket team knows this, as they recently began sending a weekly email to users with a few suggestions of popular items that you may be interested in.

This email is aimed at increasing engagement via discovery of new content, potentially resulting in more items being added to Pocket. So now Pocket has made advancements with discovery outside the app, but what’s still missing for me is a nudge to share content more than I currently do.

I rarely share content via Pocket with others. I use the app for a few minutes at a time (such as when I’m on the subway), so my focus is on reading what I have time for and then moving onto something off my device (such as getting off the train). Sharing doesn’t need to only take place inside the app — I’d explore a way to get users to share items when they’re not using the app.

The goal here is to increase virality through users sharing items. More items shared = more potential new users of Pocket. I’d experiment here with a periodic email sent to users that nudges them to share items that they’ve already consumed. This is different from the ‘discovery’ focused email described above, as here the user is already familiar with the content (it’d be a few items they’ve consumed within the past week) and can make a quick decision to share it.

• If the user is on mobile and the Pocket app is installed on the device, tapping on a sharing icon would open the app and put the user into the app’s existing sharing mechanism to complete the share based on the selection they made in the email (e.g., tapping to share via Facebook)
• If the user is on mobile and the Pocket app is not installed on the device, tapping on a sharing icon would open the web app in the device’s browser with the user auto-logged in and they could complete the share
• If the user is on desktop, clicking on a sharing icon would open the web app with the user auto-logged in and they could complete the share

The best number of items to include in the email could be A/B tested, but for the sake of this post let’s go with 4. Here’s how they’d be selected:

• If the user consumed 5 or more items during the past week that they didn’t already share, include the 4 that were most popular based on what other Pocket users have also consumed
• If the user consumed between 1 and 4 items during the past week that they didn’t already share, include all of those items
• If the user consumed 0 items during the past week, send the same ‘discovery’ email that Pocket currently sends (with no built-in sharing element)

In some cases a user will have only consumed articles and no videos, or vice versa, but here we’ll assume it’s both.

Depending on which metrics are most important to Pocket, the results of this new ‘sharing’ email (the goal being to increase user acquisition via some of the people who receive a shared item) could trump the results of the existing ‘discovery’ email (the goal being to increase engagement from the primary user).

One option is to combine the ‘discovery’ and ‘sharing’ emails to introduce a couple of new items to the user along with a couple of already-consumed items that they may want to share. This could be tested.

The following would be tracked from the emails to measure success:

• Email open rate
• Click-through rate on items within the email
• Shares that originated from the email
• New users that resulted from a share from the email

Success would primarily be determined by new users that resulted from the shares. A secondary benefit would be increased engagement by existing users who either share items or receive shared items.