If you are selling a product (or service), you are probably going about it wrong. People dont actually want or care about your product (or service). They only want what your products can do for them. You could ask..
- Does it solve their problem?
- Does it fill a void in their lives?
- Does it offer a unique experience they can’t get (or find) elsewhere?
All in all, does it help them become a better version of themselves?
Your customers aren’t buying your product, they’re buying a better version of themselves. So, don’t sell them the product, don’t talk about the features, sell them on the benefits.
Who can I become as a result of using your product? What would my life look like? Paint that picture. Help me imagine it. The sales will follow.
What are the top 5 things that you should NOT do as a product manager? There are many that I can think of. Here are just a few:
- Don’t lose sight of the vision. Why does the product you are building matter to the end-user? Or why is it going to matter? Every project (or theme) that you plan out or work on should be tied back to answer these 2 questions.
- Don’t make the mistake of assuming that you, the PM, are the customer / user. Sure, in some cases, you may fit the same demographic, but keep in mind that just because you have an opinion doesn’t mean that it counts.
- Don’t neglect your relationships, especially with your stakeholders. Strong relationships make all the difference – especially when it comes to helping you get buy-in.
- Don’t under-communicate. I cannot stress this one enough – Communication is such a vital component to being a good PM. Communicate often and using whatever medium makes the most sense. Ideally, In Person > Over the Phone > Email, IM or other forms of electronic communication.
- Don’t boss people around (even if you can). Be humble. Realize that the product gets built by the team, not (only) because of you. Sure, it might be your vision, and as a product guy you are the enabler – in charge of defining, managing and ruthlessly prioritizing product road maps, but products get built by teams, not individuals.
- Don’t assume it’ll get done on time. In my 10+ years as an engineer, founder and product guy, I have found that when it comes to software, especially complex software, things almost always take longer than initially anticipated. So, plan accordingly through effective project management, and manage upwards, so your boss/stakeholders know what to expect, and when to expect it. Ideally, you’ve made it a habit to under-promise (within reason) and over-deliver.
- Don’t worry about the how, worry about the what and why. Sure, it’s important to know whether something is technically feasible, and how long implementing it is going to take, but your #1 priority should be to figure out whatto build, and why building it is a problem worth solving. This is especially important for technical PMs that have a tendency to get a bit caught up in the implementation details.
- Don’t always trust your gut, or ignore what your data is telling you.Assuming you have enough relevant, segmented data to make a conclusive decision.
- Don’t make every decision based on data. Sure, being data-driven is important, but in some cases, you need to go with a more “qualitative” decision that is based on user testing, user feedback, and well, intuition. One good “signal” that you should base your product decision on a qualitative assessment is if you don’t have enough data to make a conclusive decision easily.
- Don’t listen to every feature request or piece of feedback that comes in. Everyone has ideas, you need to be objective about it.
- Don’t treat all your data the same. Data in aggregate means nothing. Segment, segment, segment, and segment again….because segmented data is 10x more actionable.
So, someone on Quora asked me to answer the question “What’s an average day/week like in the life of a Product Manager?”
I get asked this question from time to time, so I am posting my response here because it might be useful to more people.
What is the “typical” day (or week) of a product manager / owner like? There isn’t one. In fact, if you own the product, it’s up to you to figure that out.
Usually, my #1 priority is making sure everyone (designers, engineers, content writers, etc) on my team is “enabled”. Meaning, they know what they need to be working on, when it’s expected to get done, and aren’t blocked on anything (requirements, access, approvals, etc).
Outside of that, I spend my time doing one or more of the following on any given day, depending on the stage in the life cycle of the product:
1. Thinking about and setting the Product Vision: What is our long-term vision with this product? How does it fit into the company’s broader goals?
2. Prioritizing / Managing the sprints and backlog: What does my team need to be working on now, and what do we expect to get done in the next 1-2 weeks? Are we on track? If not, why not, and how can we get back on track?
3. Data Analytics / Analysis / Talking to customers / Looking at customer data – how are our KPIs doing? Are they trending in the right direction? Oh wait, this is interesting – there was a spike yesterday, where did that come from, and what actionable insight can I gain from it to repeat what happened in the past 24 hrs?
4. Managing expectations, and communicating goals / progress (upward, downward, sideways): Under-promise and over-deliver. Enough said.
5. “Dreaming up” ideas, Wireframing for the Designers, and writing new requirements): With just one question on my mind: Will this get us closer to our goal?
6. Evaluating / critiquing designs: Do the visual designs inspire and delight? Do they encourage me to use the product? Do we foresee any potential problems with usability or implementation? All of these need to be addressed now.
7. Dogfooding / Testing my own product and finding problems: Does my product work the way I expect it to? Does it delight me? Does it solve the customer’s problems and pain-points? Would I use the product if I wasn’t working at this company? (Remember that you have to set a high bar for everyone)
8. Managing bugs and Prioritizing customer issues (self-reported or reported by the QA team / others): Of these 100 tickets in our queue, which one(s) have the highest potential ROI?
9. Team Building — cheering the team on, resolving conflicts before they become serious issues, motivating the team (to go harder and faster), and celebrating the victories.
10. Anything else that your team needs from you: This can vary significantly depending on the company and product. In my case, this involves doing a periodic SEO analysis, coming up with potential ideas and writing topics for the content team, improving technical / on-page SEO, working with social media managers, salespeople and other stakeholders to make their jobs easier.
Ideally, as a Product owner, you’ll be maintaining an up-to-date “To-Do” and “Done” list (I prefer simplicity so I use Asana and Dropbox with Notepad++, but there are several tools that can serve the same purpose).
The most important question to ask yourself at any given point in time:”What is the best use of my time RIGHT NOW?” Weigh all the options and pick the one that’s going to be the most impactful. Be careful not to confuse “urgent” with “important”….they’re very different from each other. You know how they say “the squeaky wheel gets the grease”? Well, it’s your job to make sure the squeaky wheel does NOT get the grease at all times – weigh all the priorities before deciding what needs to be done next.
A good webpage very clearly (and simply) conveys your product’s (or service’s) value proposition with a strong call to action. The first step in designing a webpage should involve identifying what the desired user action(s) are.
For every desired user action, the only 2 KPIs that matter are:
- Number of clicks to get the user to his or her desired result(s)
- Aggregate Click through Rates to your desired destination(s), like landing pages, search results pages, etc.
- Persuasiveness of your microcopy
- Animations, parallax effects, etc.
- Fonts / Colors
- Imagery and Visuals
should support one of the 2 metrics above. If they don’t, they’re a distraction – ditch them.
This was a guest post featured on Mind The Product, an international product community. Mind The Product started in 2010 with the very first ProductTank meetup in London and followed by the Mind the Product Conference in 2012 it has now grown to consist of 2,500+ members and sold out events in 12 cities around the world.
As product managers and entrepreneurs, we know the importance of validating an idea before committing to getting it built. However, validation is easier said than done. In fact, it’s possibly one of the hardest things you will ever do in your product life cycle, otherwise products and startups wouldn’t have the abysmal 90%+ failure rate they’ve become famous for.
In this post I will draw on what I’ve learned over the years, through first-hand experiences and other sources and leave you with a validation framework that I hope you’ll be able to use. And, in the remote case that you’ve been living under a rock and the whole lean startup movement somehow got past you, this post will try to bring you up to speed (and possibly, get you slightly ahead of the pack), provided you force yourself and your team to take action!
- When it comes to new products, by definition you’re making assumptions, sometimes a lot of them. You need to validate your key hypotheses and assumptions as early as possible. Some of your assumptions are going to be wrong. If the ones you get wrong are significant, you’re not going to be in business for very long.
- Validation will help you avoid the most common problem of them all, spending time and money building something nobody wants. If you ever come across a failed product, chances are that it was based on an idea that the founder was enamoured by or found cool and interesting, rather than something that solved a real pain point for real people.
- Validation also forces you to get in touch with your users, which could save you the pain of building a product that is hard to use or understand, or something that is ahead of it’s time. (Remember Webvan?)
- If you figure out that you’re headed down the wrong path, it’s also easier (and a lot cheaper) to change course sooner rather than later. And, it’s all the less likely that you’ll have to pivot later.
- Validation will help you refine your ideas and learn more about your users.
- And last (but certainly not least), it will help you figure out if people will buy your product before you build it.
Validation will help you answer questions like:
- What is the target market that I want to address? How big is the addressable market size?
- What is the biggest problem these people face? Is it an isolated or recurring problem?
- What kind of product would help relieve that pain?
- Are there real people willing to pay for such a product if it existed?
- Will building it be worth it? Or, is the market big enough?
- And, am I building the right product?
So let’s get to it.
What Should You Validate And HOW?
People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!
We need to have a clear understanding that customer needs are separate and distinct from the solutions that people buy to address those needs. Keeping this in mind, validation comes in many forms:
- Validating market demand
- Validating the customer problem/pain point
- Validating the product or solution
Validating demand and validating the problem come first. Then you come up with a solution (a prototype or design of your product) to solve the problem that you have identified. Finally, you validate the product you have thought up, separately. Validating the product you have imagined (before building it) is important, because there are a gazillion ways to solve the same problem.
The goal of validating demand is to get an answer to the question:
What is your total market potential, and how much of that market can you/will you be able to capture?
Here, you want to work out a realistic market size that is feasible, otherwise you risk there not being enough demand for the product because it doesn’t solve a big enough problem for its market or it doesn’t solve the problem in a way that works well for users.
You want to ensure that the market is big enough and that there are enough people willing to pay for your product or service. Ideally, at the end of this exercise you should be able to understand your users’ interests and motivations better, and hone in on a small group of people who feel enough pain to buy your product. Also, if done right, you’ll be able to use what you’ve learned to find similar (or parallel) markets to expand into in the future.
Be sure to hone in on a specific target market where the constituents have similar behavior patterns. It doesn’t matter if it is small, as long as it is sizable enough and there is potential to expand into other niche markets in future. For example: music lovers is too broad;college students that listen to punk rock music is better.
Methodology, tools and techniques for validating demand:
- Industry reports
- Look at traffic of competing websites, using tools like comScore,Compete and Quantcast. If you know that your competitor has 1 million unique visitors per month, at the very least you know that the market potential for your website is 1 million.
- Google Adwords Keyword Planner – use the Google Adwords Keyword Planner to determine how many searches related to your market take place on Google each month
- Look at Google Trends data to look at search query volume
- Look at competitor offerings and try to find (or make an accurate guess of) pricing and revenue numbers
- Note: Be wary of forecasts of market size, many of which use questionable methodologies or flawed assumptions
Validating The Problem
The goal here is to make sure that we find a real problem or customer pain point that enough people face, so that we can later focus on solving that problem.
Methodology, tools and techniques for validating the problem:
As Laura Klein mentions in her book UX for Lean Startups:
Now that you’ve picked your specific market, find five people who are in it. If you can’t do this fairly easily, either you’ve picked too small a market, your market is too hard to reach, or you’re just not trying hard enough.
Don’t just go out and start talking to friends, family and random strangers on the street – that could be a mistake. These people are (likely, but not always) going to be very different from your target market. Go where your REAL target users are, observe what they are doing, and think about how you can make those tasks better and/or easier. Sometimes, your users are out there in the real world, but sometimes they are more easily accessible online (for example, on discussion forums, Facebook groups, and online review sites like Yelp or Epinions, etc. If possible, schedule a Skype call with them.)
Ask them open-ended questions about the tasks they go about doing in the identified problem domain and the pain they are experiencing. Ideally, they will be able to show this to you first hand. This will help you learn how people do things, why them do them a certain way, and also what solutions or workarounds they are currently using to solve their problem.
Look out for patterns – groups of people doing things the same way, or complaining about the same thing and either observe or ask them how they solve those pain points today. Keep in mind, however, that sometimes users don’t know they had a problem until they’re shown the solution (your product). Dropbox is a classic example of that. Just remember that you’re there to observe, listen and learn – not to sell your test subject on your product idea.
This kind of thing can have a big impact on your product implementation, your user interfaces and so on and will help you ensure that your product more naturally fits into the daily lives of your customers. It will help you minimize the amount of training you will have to give your customers once the product gets built because they don’t have to learn new habits to use your product, thereby shortening abandonment rate and increasing the likelihood of the customer sticking it through after the first interaction with the product. It will help you trash bad ideas that you were previously considering very quickly. All this before you start building anything. At the end of this exercise, you should be left with a validated problem in a validated market.
Validating The Product Or Solution
Ideally, building and validating the product should go hand-in-hand and be an iterative process, with some amount of validated learning along the way (or at the very least, with every iteration you make). This is the final step and comes after validating demand and validating the problem. It involves constantly asking yourself the question: ‘Does this product really solve the problem, in the market we have identified?’. Product validation is more complicated and should be done via iteration. Ideally, it looks something like this:
Methodology, tools and techniques for validating the product or solution:
You can use landing page tests to market and sell your product before it even exists. Now, drive relevant, targeted traffic to your landing page using some marketing channel (free or paid) – Google Adwords, Facebook Ads, or anything else you can think of.
If you’re unable to generate enough interest in your landing page tests before you have a product, it either means that your marketing strategy isn’t good enough (in which case A/B testing more landing pages is the way to go), or you’re trying to sell a product that there isn’t enough demand for. This is not to say that the problem you have identified cannot be solved in another way (you have validated the problem already, after all). It just means that you need to create a different solution for the problem. This approach drastically reduces your chances of failure when you eventually hone in on a product worth building and also helps you prioritize your product features based on how users react to your marketing copy. Landing page tests have the added advantage of validating the market at the same time, so you could start here if you have already narrowed down a problem you want to solve.
Once you have validated the idea, you need to validate the product you have imagined (before building it), because there are still several ways to solve the same problem. The best way to do this is by showing potential users a semi-functional (or even easier, a non-functional, but interactive) prototype that looks and feels like the product. This is as opposed to asking them for an opinion on your idea, which bears no correlation with real people using your product).
Then, you (silently) observe how potential users interact with your prototype, looking for common problems, symptoms and patterns, find out if it’s compelling enough to pay for, and course-correct if needed. Just don’t bias your test subjects by treating them as potential customers – now’s not the time to sell them on your product. If they don’t ‘get it’, either because they don’t understand what it does or how to use it, or they’re unable to find all the features, that’s an obvious sign that something needs to change. As you can see, including prototyping in the product validation cycle will both help communicate your ideas and allow you to harness the power of failure to create something truly innovative.
You could also make your users interact with your competitors’ products, to uncover holes in their products that you will smartly fill.
You may have to iterate through a number of prototypes before you end up with a validated prototype at the end of the exercise. The same validation would then have to be done for your designs and, eventually, the end product you are building.
The validation story doesn’t end here, of course – it goes on at every step of the product life cycle. And then again later, after the product is out there, every time you fix a bug, add a new feature or make a product change.
A few resources worth mentioning:
- fivesecondtest.com – to help you guage a user’s ‘first impression’ of your exer experience or design
- unbounce.com – to help you create landing pages easily
- aytm.com (ask your target market) – could be a useful tool to find your target market and send them surveys
- optimizely.com (Google Analytics also offers A/B testing functionality) – to run A/B tests and measure click-through rates on different page elements
- usertesting.com – to help you get real user feedback (though, not necessarily from your target demographic)
If you use validation the right way (at every step of the product development cycle, and are disciplined enough about it), your customers will practically lead you to the goldmine, telling you virtually everything you need to know to make your product a success.
- Wanna Create A Great Product? Fail Early, Fail Fast, Fail Often
- UX for Lean Startups: Faster, Smarter User Experience Research and Design by Laura Klein
- Creating A Killer Product
Here’s another tip on how to approach the problem of Designing for Community.
Tip: Passionately, mercilessly commit to enforcing one rule: “Be Friendly.” Using this simple principle is how Javaranch built a large community. Now, you can still have a huge community without that rule, slashdot being a good example. But if you’re trying to inspire passionate users, enforcing a “Be Friendly” rule can be one of the best moves for long-term growth and retention. However, this does come at a cost – a small portion of your community is going to complain about the censorship you are enforcing and the “lack of free speech”, and they may leave. But then, you probably don’t want those people to be part of your community anyway.
Here’s another tip on how to approach the problem of Designing for Community.
Tip: Enforce a strong and consistent culture. A community can work with virtually any metaphor, “Be Friendly” or “Be Nice” just being one example. If your community has a strong and consistent culture, whatever that culture is, the community starts moderating itself. When enough people are behaving in a certain way, and that hits critical mass, it becomes not only accepted but obvious to everyone when it’s being violated. Violators are naturally discouraged from indulging in disruptive behavior, and weeded out of the community.
I was reading this blog post by Andrew Chen on the importance of designing for community. Got me thinking.
In his blog post, Andrew gives the example of Dribbble, the site for designers that curates new community members in the form of “drafts” or community nominations. Great example, but other than this, Andrew doesn’t get into the specifics of how one can successfully design and foster online communities.
Why is Community so important?
It’s a noisy world out there, and it’s only getting noisier. When it comes to building a company for the long-term, few things matter more than community. In fact, if there’s one “magic bullet” with the potential to cause one small, 13-person start-up to be valued at over a Billion dollars, I would venture to guess that the answer would be Community.
Yet, relatively little has been written about this critical element of building long-term start-up value. Why is that? And why are we (“we being the start-up community) so focused on talking about marketing, PR, Social Media and “Virality” instead?
I think it’s three things:
- Designing for, and fostering a large and engaged community is hard. It requires a lot of thought, care, and most importantly, patience. (Now, my definition of community may be different from yours. To me, a community is an actively engaged set of users that interact with each other frequently. A large community consists of anywhere from a few hundred thousand to several million active users.)
- Building a community is a highly specialized problem, very specific to the start-up in question.
- It could just be a general sense of lassitude, but as a culture, we are mesmerized by objects and experiences that grant us the promise of immediate gratification. We want results and we want them now, without having to invest a lot of time or money into it. It’s not hard to imagine then, why we would much rather get our hands on a shortcut or gimmick that promises to propel our obscure startup into the technological hall of fame, over doing things the long and hard (albeit tried and tested) way.
That said, I do think that there are some common elements to designing communities. Wouldn’t it be great if someone took the time to create a “Design for Community Playbook” to help the rest of us? Yes, yes it would.
But first, what are some of the common characteristics of a community? And what makes a community a community? Understanding this is critical to “hacking” our way into designing successful communities, and in turn, building long-term value. Courtesy this great presentation by Joshua Porter:
- Software doesn’t make communities, people do.
- You don’t create communities, you cultivate them.
- You probably have a community whether you know it or not.
- Communities change over time; they grow and evolve.
- Communities need to be managed.
- Communities form around activities, not necessarily software.
- You can’t own a community.
- Not everyone gets along in a community.
- Community is more than support, it’s about getting better.
In fact, one of Joshua’s key points is that software that connects product users and lets them help each other is the most efficient way out. When you support an activity, when you make people better at that activity, by either helping them directly or helping them help each other, then you gain the opportunity for that group of people to call themselves a community.
Another key point – the benefits of having the community scale as the community grows, and the cost of maintaining and managing the community accordingly diminishes.
Hopefully you’re now sold on the importance of an online community and it’s benefits. But what are some key things you could do to foster and grow a community of active users for your start-up? Over the next series of posts, I’m going to throw a few ideas your way – so subscribe and stay tuned for updates.
Some 13.7 Million years ago, there was a colossal Big Bang, which created our universe, and is the reason we’re all here today. In a trend not all that different, and with 246 million registered Domains as of 2012, the internet footprint has exploded in recent years, and it’s showing no signs of slowing down.
With the white-hot battle for eyeballs and companies / websites vying for our attention, it’s not hard to understand why our attention spans have shortened in recent years, to the point where user loyalty is at an all-time low and on the verge of extinction.
As entrepreneurs and product designers, it is therefore critical to focus on our users more so than ever, especially during that early acquisition and onboarding flow, to guide our first-time user through the experience, ask for information we want from them, and show them features and functionality that they need to get accustomed to, so that they may find our product or service useful and (hopefully) come back a second time.
In that vein, and in order to design our login experience and onboarding flow to be as effective as possible, we need to keep asking ourselves questions like:
- How can we make login as quick and painless as possible (ideally a 1-click experience)?
- Does Facebook Connect / Sign in make sense? How can we make the user login / signup using Facebook (instead of email)? The obvious advantages here being convenience, one-click signups, social integration and access to rich social data that we’d otherwise have to ask the user for.
- What does the user need to know when he logs in the first time?
- What information do we want the user to answer?
- What information do we want from the user via other means (facebook connect, etc)?
- What features and functionality do we want to show the user (like a tutorial that is shown by default for the first time, but can be manually invoked again at a later stage)
- How do we motivate users to become ACTIVE contributors (instead of passive readers and content consumers)?
- How can we add a certain degree of randomness / unpredictability to that first login / onboarding experience? (we tend to dismiss the boring and unpredictable but pay attention to things that we’re not expecting)
- How can we motivate and incentivize the user to come back?
The login and onboarding process should be a key piece to the success of our product and user experience. It’s our one chance to create a (strong) lasting impression. Without it, the rest of the features we build simply will not matter.
If I’m missing other questions we need to be asking ourselves, please leave a note in the comments below.
What is Fake-door testing?
It essentially is a variant of A/B or multi-variate testing, and is becoming increasingly popular among startups and Internet companies (TripAdvisor claims to be using Fake-Door testing extensively, and I am sure other smart companies do so as well).
Fake door testing is a technique used by companies and product managers to avoid having to spend a lot of time (and money) building out a new product or feature before knowing whether it’s something users are going to want to use. It is an easy way to tell whether or not you should invest time and money into your next great product idea, based on a quantitative assessment of whether it will be used by your current user base.
One caveat here is that fake door testing is only statistically relevant if you have an existing user base, and you are able to collect enough data for the results to be statistically significant.
The way it works is as follows: a certain very small percentage of your end-users (say 1%) are directed to or shown a new button / page / user-interface, while the remaining 99% of users don’t see it. These 1% of users do not know that the feature they are attempting to access doesn’t exist yet…and so they are the proverbial guinea pigs as part of this “fake-door” test that leads nowhere.
What’s happening in the background is that every action taken by this 1% cohort (clicks, form submits, mouse overs, etc) is being tracked.
Once enough data has been accumulated, it’s easy to figure out if the feature is desirable or not and whether or not it will be used, before having to invest several man-months into building it out.
Do you or your company use fake-door testing? How and what are you using it for? I’d love to hear from you in the comments.