People don’t buy products and services, they buy benefits and experiences
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?
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.
What’s an average day/week like in the life of a Product Manager?
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.
Good Webpage Design: The only 2 things that matter
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.
Everything else:
- 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.
Designing for Community : Mercilessly enforce one rule: “Be Friendly.”
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.
Designing for Community : Enforce a strong and consistent culture
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.
Designing for 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.
Why you need a KILLER Login and User-Onboarding flow
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.
Using “Fake-Door” testing to make better product decisions
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.