I love addiction; perhaps because I have a very addictive personality. As such, I was drawn to the talk here at South by Southwest by @taraattrulia about engineering addiction. She’s going pretty fast, so I will.
Three strategies to get to stick:
My reflections on the talk are as follows: I think it was heartfelt and interesting, but I failed to see any real connections to addiction. The talk description mentioned stuff like neuroscience; but I the content was not specific or in-depth enough to make me feel like I really learned something deep. Cool pillars, though.
Through a recent newsletter from the Silicon Valley Product Group, I came across a great article by Marty Cagan about, product evangelism, which I see as essentially helping people to imagine the future and inspiring them to help create that future by “selling the dream.”
In that piece, Cagan lists his top 10 pieces of advice for product leaders who want to sell the dream:
I really hadn’t given much thought about product evangelism as a thing until I read the article, and then I thought, “That’s really cool.” I’ve always been more concerned about the opposite problem – too much dedication to a product idea where you can get so dead set on a vision that you end up constraining the creativity of the team. (See Ideas are worthless, execution is everything.)
In general, product evangelism becomes important because everything in life is built on what I call a narrative. You see something happen, or in the case of a product you see a feature that doesn’t make a lot of sense to you so you build a narrative in your head. A personal dialog that justifies what you’re doing, even if you don’t agree with it. Maybe something to the effect:
We had a dumb designer and he came up with this idea. I’m just doing what I have to, but in time I’m sure it will be easier to see that this will never work.
The problem is, the narrative may not be true at all. More often than not, narratives may be based more on mistaken perceptions than on reality.
Within a pure product organization, controlling the narrative is 90 percent of your job. In essence, everyone is very close to the product and its development and knows what’s going on. But if you’re not in a pure product situation – where other groups exist beyond pure product development – there will be people who don’t know what’s going on or why you chose the product you did. The narratives they create may be far from the truth.
The beauty of product evangelism is that you’re creating the narrative for the people around you so they can build a mental model that includes aspects like:
And in so doing, you allow them to incorporate what’s important in their narrative. So in that sense, by becoming a product evangelist you control the narrative.
To me, the most important items included in Cagan’s 10 pieces of advice are items 4 and 5 – share learning and credit generously. I think they’re most important because they’re the hardest. You absolutely have to do those things if you want to be a good leader. Unfortunately, it’s what I see the least of, not only in myself but in the people around me. Sharing what you’ve learned and sharing the credit should be a requirement, not an option.
I think it’s surprising, given how critically important product management is to most tech companies, how few people really know anything about it. A lot of companies (including tech companies) either don’t have a Product Management person or the Product Management function doesn’t exist at all.
So where should the Product Management function live on the org chart? Obviously, there’s no one-size-fits-all answer. The answer depends on:
If you’re running a product-based technology company, the Product Management function needs to be owned by someone in the core inner circle of the business, such as a C-level officer. If your business is product based, it’s critical that your Product Manager have a seat at the executive table. You shouldn’t have products reporting into someone who reports to the CEO.
In a startup that’s especially true. In a lot of early-phase tech startups, the Product Management function is actually run by the CEO or founder himself/herself – the person who incepted the idea for the business. There are a lot of B2B startups where the CEO only focuses on products because he or she had the idea in the first place.
But the CEO shouldn’t be completely enveloped in products alone. The CEO needs to be thinking about all the moving parts of the business and not just products. In some cases, you’re better off bringing in an outside CEO because if your CEO is focused solely on the product itself, who’s going to focus on getting it sold?
For companies where technology and products are not the core of the business, product management doesn’t need to report to the CEO. One approach might be to have product management report to a C-level officer, such as a CTO or CIO who reports to the CEO. If yours is not a technology business, but technology is an enabler (such as Ford or DelMonte, e.g.), product management doesn’t really need to have a seat at the executive table. Instead, it can proxy through someone who does have a seat. However, it’s still important that the Product Management function exists and gets proper attention even if technology is not core to your business.
The question of scale, or where you are in your business growth trajectory is also important when it comes to product management. For example, eBay is a business where the whole business is the marketplace. They don’t stock merchandise or make their own products. All they do is connect buyers with sellers.
eBay’s ‘product’ vision for the marketplace is core to the business, but in this case it may not make sense for product management to report to the CEO because the company is highly decentralized. Each part of the business has its own General Manager or Vice President. Groups are broken into subgroups and each sphere has its own product person.
At eBay’s scale, decentralizing product management makes perfect sense. In smaller businesses, decentralizing product management is generally neither necessary or wise.
The most important thing is that product management needs to be recognized as a function. Someone owns it and has the necessary autonomy to make important product decisions. However, your CEO should not also be your VP of Products unless the rest of the executive team is strong enough to make sure other aspects of the business are getting the necessary attention.
What you don’t want to do is tell someone they’re responsible for product management, dictate to them what has to be included in the product and then make them responsible for product metrics, too. A true Product Manager cannot be accountable for any metrics if you’re telling him or her what features to include in what order. They have to truly own the Product Management function.
If a Product Manager is not empowered to really do the job, that’s okay but don’t give them a title such as VP of Products. Give them a more appropriate title and say they’re a Program Manager or something. Don’t mislead them or anyone else by calling them a Product Manager when they’re not.
Trying to deliver great customer service without bowing to irrational client demands takes a somewhat tricky balancing act and some courage. The truth is, the customer is NOT always right. At end of the day a lot of companies have adopted this sort of thinking:
“The customer isn’t always right, but you want to do what’s best for everybody in the aggregate – for the good of the many.”
The reality of the situation is that no matter who you are – even a brand readily known for its exemplary customer service like Zappos – you still have scarce resources. You don’t have unlimited customer service people. That’s why I think the secret is to try and focus on what makes everybody’s life the best.
Excellent customer service is paramount to the success of any business. At one time, customer service was so bad, if you did well you could really stand out (back then bad or mediocre service was considered ‘the norm’). A number of companies proudly proclaimed great customer service as their competitive advantage. And I tend to agree with that, even today, when I think of a company like Zappos.
Today, you really can’t start a business without strong customer service from the get-go. You can’t succeed at something new if you have lousy customer service. It just won’t work. If you want to get in the game, excellent customer service is what you have to do because that’s what people have come to expect. So instead of a competitive advantage, it’s become the price of admission just to get into the game.
You want to treat every one of your customers with respect and courtesy – that should never change. But not all customers are created equal. I’m not saying they shouldn’t all be treated with some baseline level of respect, but the people who are your best customers – you need to recognize that. It pays to scale up in how you treat people based on what type of customer they are.
A good example of this is Southwest Airlines, who treats all customers with respect, but whose best customers get special attention and the most respect (through the Southwest Rapid Rewards program).
Crazy customers do exist, but it’s all about the net effect they have on your business. The balancing act is you’d really like to provide even your crazy customers with good service, but if you do it’s going to end up at the expense of good quality service for someone else.
There are those ‘toxic’ customers who don’t treat others like human beings. Always treating your customers with respect doesn’t mean you have to entertain their level of ridiculousness. I don’t want my customer care rep on the phone for 4 hours literally getting berated. That rep. is not going to be on the top of their game for the rest of the day to provide great service to the good customers.
True, some customers will be worse than others. Just make sure the worst don’t become a liability – where your net customer service score (or Net Promoter Score I’ve discussed in the past) is worse because you’ve spent too much time on the irrational few.
If you go out of your way to tailor your business too much to the squeakiest wheels, you end up under serving those who are not squeaky wheels.
The customer is NOT always right: there will always be those who take advantage of companies. That’s just the way it is. But you need not let that bring you down.
Find ways to curb the downside risk. Have ways to flag those customers. Have outs to be able to say, “This customer is someone we know who is negatively impacting our team, so we need to have ways to cut the engagement down.”
Companies still have the right to refuse service to ANY customer. You want to avoid discrimination, but beyond that you should be able to say, “We need to cut this off.” (Check with legal first if there are any doubts.)
Refusing to bow to irrational customers isn’t profound. It’s obvious. It’s just that not everybody does it.
I’ve always believed product management is all about discovery. As time goes on, I’m seeing that others are also beginning to get on the bandwagon and think it’s a cool thing to believe. But I get confused because there are still so many people – especially entrepreneurs – are so confident their thinking is right that they don’t see the need to verify it or even listen to what other people are saying. Because they are entrepreneurs they are remarkably self assured. They’re extremely confident and believe they’ll do well, so they say, “This is how it’s gonna look, and boom – we’re going to make 10 million dollars.”
I’m not faulting the mindset of entrepreneurs. I think they should be “beacons of irrational optimism.” You need someone to be that force of positivity. One term that’s been used when referring to Apple’s Steve Jobs is Reality Distortion Field, or RDF. Jobs is such a believer in what is to come many say reality is actually distorted around him. His charisma is so contagious that suddenly all around him believe they’ll move mountains. So if this sense of confidence works so well, how can it be wrong?
First, Steve Jobs is not making those products – he’s the visionary leader who’s talking about what the future could be. I’m not an insider at Apple but I assume he’s not in the product war room hands-on managing the product.
My theory is that most product people are not hired – they’re founders/CEOs. I’m not saying being irrationally optimistic, or being a believer or being an entrepreneur is a bad thing for products. At the same time, that instinct is what drives entrepreneurs to be bad hands-on product managers. “Why do user tests” Why do A/B tests? I know this is going to work.” When I hear that, I know these are going to typically end up as someone’s famous last words.
The verb “discover” is a very critical part of the term “product discovery”. When using the term product discovery, people too often overlook the action part of the word “discovery” (to discover). To me, “discovery” means you’ve found something out – like something or some place exists that you’ve discovered. It indicates the product is bigger than you – there’s this natural environment out there and it’s your job to discover what’s out there. It’s not called products “creation” it’s called “discovery” meaning there are answers out there for you to find and those answers are found through the users of the product.
If I had to define the term product discovery, I’d say it’s:
“The act of ideating with the feedback of your users in an iterative way that enables you to find the right product.”
The way to build the best stuff is to find out what people really want and would use. But there are companies out there that are spending millions on products that apparently did not get user testing. We all know epic sales launches that have turned into epic failures. People can go a long way without verifying what’s actually valuable or viable.
There’s a difference between discovery and validation. If you have one bullet to fire – and ask yes or no questions – you’re not doing discovery, you’re just validating. If you’ve already predetermined everything and test that on users, you’re not really discovering.
Discovery means being open minded. If you’re close minded you’re really not doing discovery. Bring user feedback in the game all the way through the process – even early on, with wireframes, and linking together within prototypes and all the way up the curve bring users in to test to make sure there’s actual value for the user in the interaction.
Good discovery keeps products in low fidelity longer (see my rapid prototyping post for a discussion of low and high fidelity prototypes). Those who do product discovery best understand the importance of low fidelity prototypes because instead of just testing one thing they have 4 or 5 different approaches to the problem and they’re testing those approaches well before the high fidelity stage is reached.
There’s an inverse correlation between fidelity and ideas. Early on there are lots of ideas that need to be tested, first in paper and pencil sketches when you have, say, 5 ideas. By the time you get to mockup or wireframe made, you refine your ideas from maybe 5 to 3 and continue learning from that until you start to create 2 prototypes and then 1 polished interface as you close in on the core idea. That’s what discovery is all about: going from low to high fidelity and getting feedback throughout all phases of development.
The concept of product discovery has always been intuitive to me. If you want to be world class at building great products you need to be willing to accept the fact that you’re going to be wrong from time to time.
I first read about Net Promoter Score on Eric Ries’s blog almost a year ago. I found the concept to be really compelling. In recent conversations with lots of budding entrepreneurs, I have realized that not everyone is really familiar with NPS. So I thought a quick overview could be helpful.
The term ‘conflict’ typically carries with it negative connotation. But it’s something I have been thinking a lot about lately, and I feel like conflict is not necessarily a bad thing. As our company continues to grow at a very rapid trajectory, there are lots of new faces, roles, and even whole organizations. Managing the responsibilities and roles during the growth has been a challenge, to say the least. The reality, however, is that friction in this kind of situation is unavoidable. I’d even go as far as to take that a step further. I am not sure I want to avoid it. I think that open and healthy dialogue about disagreements can be a good thing.
I was happy to see that my thoughts on the topic of conflict were seconded by many authorities in the management arena. There is a fascinating book titled: “The Right Fight”, which espouses the belief that conflict is a welcome element in any organization. The authors have coined the term “productive dissent”, which is essentially harnessing the power of well organized and respectful debate.
For most people, including myself, the last thing we desire is an argument. However, when working in a collaborative environment, some level of conflict is unavoidable. The key is using disagreements as a catalyst to improve our overall work environment and customer experience. This may sound far fetched, but I have seen where productive dissent has been a powerful tool.
If you think about it, to stay competitive in the marketplace, a company must continuously evolve. Stagnation literally equals death, no matter how good your initial product or service is. Technology, the competition, and customer expectations will demand constant improvement. Embracing the principles of the “right fight” is a great way to stay on the cutting edge.
So, what does that really mean?
I am very fortunate to be a part of an organization filled with extremely intelligent and motivated individuals with diverse backgrounds of experience. However, inherent in this is the fact that, at times, we may disagree with each other about the specs of a project, the ideal organizational structure, or the best process. Instead of agreeing to disagree, we should instead aim to get all thoughts and perspectives placed on the table for consideration. When you approach issues in this way, wonderful things can happen.
It’s often not until you really get into someone else’s thought process by allowing full and honest discourse, that you uncover the gems of innovation and creativity. In this Euntreprenuer.com article titled “Conflict in the Workplace”, the columnist stresses the point that for a leader, “How employees deal with conflict is usually a direct reflection of the tone or atmosphere you set for your company. If you shy away from conflict, so will your employees. If you confront others in a negative manner, so will they. If you embrace conflict as a potentially positive engagement between individuals or groups, they will, too.”
This statement made me reflect on my own management style and manner of handling conflict. While I always make a conscious effort to be inclusive of the viewpoints of others, I am sure that I can do more to foster a culture that appreciates and grows from any disagreements we may have. My ultimate goal is progress and I fully embrace it — no matter what the source.
Jeff Weiss, a prolific author on collaboration in the workplace is quoted in the Harvard Business Review as saying “Assume you have something to learn, assume there is a more creative solution than you’ve thought of.” This wisdom, along with striving to identify common ground and branching out, are keys for the successful resolution to workplace conflict. This is advice that can be used in our interactions within the company structure, as well as in our everyday lives.
To me, good teams are built on healthy relationships. Healthy relationships don’t mean that avoidance of conflict. In fact, they mean quite the opposite. Healthy relationships are about trusting someone enough to share your honest feelings with them, even when that means you disagree. In the end, you and the other person are better for it. And perhaps most importantly, the whole company is better for it.
The next time you encounter a conflict, employ the principles of the “right fight” and observe the outcome. I would love to know how it works out for you. (I’ll certainly let you all know how it works out for me…)
I don’t like requirements documents. There, I said it. I’ve been thinking about this latently for a number of months now, but all of this thinking really caught up with me this weekend. We’ve been thinking a lot lately about evolving our product management practices and there are no shortage of opinions around the office and from experts in the community. As such, I’ve tried to do a lot of listening, reading, learning, and reflecting over the last few weeks. Here’s what I’ve come up with so far.
There are many flavors of requirements out there. Depending on the product management practices you use, you are likely to have some of the following: product requirements documents (PRDs), market requirement documents (MRDs), business requirements documents (BRDs), software requirements specifications (SRSs), and feature specifications (FSs). For the sake of simplicity, I’ll just refer to all of them as PRDs or specs.
There are a number of shortcoming with PRDs. I’ll take the time to just list a few here:
To me, a good set of requirements is supposed to describe a product that we are reasonably confident will be successful in front of real users. But why does it exist in the first place? Well, it’s core purpose is to facilitate discussion and decision making around the product in question. Typically, there are a lot of stakeholders (with a lot of different paradigms) around that table: QA, Engineering, Marketing, Merchandising, Operations, Executives, etc. So a good spec is able to quickly communicate what this product does and how it will do it. The goal of such a specification is to create more clarity than confusion. It should be your single source of truth. Finally, a sustainable spec is one that is built for change. Your product will no doubt evolve and change as you gain more insight from users.
Delivering on all the expectations of a good specification is much easier said than done. There are a lot of things that a spec has to do, and it’s only really useful if you can create it in a reasonable amount of time. Furthermore, in most typical formats, the spec ends up getting thrown in the trash after the product is launched. So you really don’t want to invest that much time into it.
Also, there is a timing issue here. How can we have any degree of confidence that our product will be successful without actually having tested the product in front of real users? If you look at most specification creation processes, you’ll find that people are writing tens or hundreds of pages well-before they’ve actually put anything in front of a user. What’s worse is that they haven’t even begun to think about the interaction or visual design of the product yet. That’s counterintuitive to me because it goes against the most important rule I have learned in my time managing products: The user experience is the most important part of any product. It’s not about ‘what it does.’ It’s about ‘how it does it.’
Now don’t get me wrong. Some really forward-thinking product teams actually pay close attention to interaction design and visual design in their PRDs. Some of them actually sketch out ideas and test them in front of users while building their requirements documents, which is a huge win. If you are in that select group of forward-thinkers, you are definitely a step ahead. But, in this scenario, there is an obvious question that we are left with: if you are actually beginning the process of product discovery (and doing real user testing), why are you using a document as the format to store your findings and insights?
When we look at all of the things that a specification is supposed to do well, it becomes clear that building a good one is a really tall order. But when we combine the goals of communicating the needs of the product with actually validating/discovering the solution, an answer emerges: a high-fidelity prototype!
The beauty of a high-fidelity prototype is that it actually provides people with a realistic sense of the user experience of the product. A good prototype describes the functionality of the application while leaving very little room for imagination. High-fidelity, to me, means that the interface is clickable, but that the backend is not necessarily functional. In most cases, it will be ‘stubbed’ or simulated. While every single corner case need not be designed, the major use cases and features should be fleshed out. After all, the idea is to capture the proposed user experience.
Imagine the kind of robust dialogue that can be had around a high-fidelity prototype versus a 50-page spec. All of a sudden, these disparate stakeholders with very different frames of mind, will all (literally) see the same thing. They will not only have a sense of what the functional requirements are, but they will see the proposed information architecture, user flow, interaction, and visual design. They can actually understand how this product will come together and will have a much more robust understanding of what it means to them. Also, they’ll have a single source of truth. No need to dig through several email chains to find the answer to the question about a certain use case. Just click through the prototype to find your answer.
If you think a high-fidelity prototype will help facilitate discussion and decision making around a product, just wait until you see what it does for your engineering team. Beginning engineering without having fleshed out the user experience can be very costly. Typical specs are so ambiguous that the really tricky product management decisions are faced only after the engineers have begun writing code. Also, typical written specs leave so much open to interpretation that its very likely engineers will write code that doesn’t do precisely what you intended. This usually creates time pressure for PMs and engineers. The pressure generally causes them to make hasty decisions without user input and to re-write code without taking the time to be thoughtful.
But a high-fidelity prototype changes a lot of that. The experience has been thought through much more significantly by the time the engineers begin writing (back-end) code. Furthermore, there are few (if any) better ways to communicate the needs to an engineer than to show them precisely how the application is supposed to behave. They can actually foresee some of the challenges ahead and can be much more thoughtful about the architecture. That’s not to mention that their velocity is likely to increase because they have more clarity on what they are building.
Last, but certainly not least, is the effect on the user. The great thing about using a high-fidelity prototype as your ‘source of truth’ is that you can actually put it in front of users to get feedback. This enables you as a product team to ‘test early and often.’ And instead of taking all that extra time to ‘write up’ your learnings from user testing, you can just work with the interaction team to evolve the prototype. Which means you can iteratively test it again and again until you’ve gotten the experience right. You are able to test much more easily at this stage because the cost of change is so much lower than it will be further downstream. Once you are ready to begin implementation on the prototype, no additional administrative work is needed (in the form of writing pages and pages). Instead, you can just begin involving engineering in the discussions around the prototype and they can begin turning it into a real product.
If you’re a skeptic right now, that’s OK. It’s likely that your existing process is painful enough that you’ll get open-minded about this sooner or later. Next time you have the opportunity to create a product spec, you should consider working with your design team on creating a prototype instead of spending weeks or months writing a longer PRD. Get that prototype in front of real users (and the rest of your product team and stakeholders) and use it as a catalyst for dialogue and decisions. When it comes time to implement, bring your engineers into the conversation. I think you’ll be pleasantly surprised at the result.
One of the questions that gets escalated to me most often these days is some permutation of, “What is the difference between product management and interaction design?” It is particularly hard to answer questions like “where does one end and the other begin?” These are not simple questions to answer because the roles do have some overlap and it is important that both of these roles collaborate closely in any organization.
Before I answer the question, I should say two quick things:
To me, product management is really about two things: 1) defining and assessing the market opportunity. 2) working with the cross-functional product development team to discover a solution. Here are some of the core activities that come to mind:
Of course, the job of a PM on a good product team becomes very iterative. Few, if any, good products are developed linearly. Instead, new information and insight is yielded throughout the process, which drives updated requirements and solution-validations.
Interaction design (IXD) is a partner organization to the product organization, much like engineering is. (More on this later…) An IXD’s goal is to build something that is usable and valuable for the end-user. A good IXD gets at this goal in two ways: 1) getting to know and understand the user 2) thinking through (in detail) and ideating potential experiences for the user. Some of the core activities that come to mind:
The interaction designer has a lot of work cut out for herself. The key to doing a solid job is to have the time needed to do the right kinds of discovery as well as being iterative in conceptualizing solutions. Again, learning about the customer is not a linear process. Often times, new information and insight is brought to light in the middle of the design cycle. This is why being agile and iterating on design is so important.
It doesn’t matter how detailed we are about dividing up roles and responsibilities between IXDs and PMs. At the end of the day, they both have a lot of shared responsibilities. They both need to be connected to customers and stakeholders. They both need to be iterative and work with end-users to understand if needs are actually being met. They both need to be willing to change their deliverables (whether they are product requirements or prototypes) based on new insights that are brought to light.
Product management and interaction design is a close collaboration no matter how you slice it. I view PM as a bit higher-altitude when it comes to defining a solution. IXD is closer to the ground, and has much more of a hand in defining how the experience comes together. While both groups need to work to respect boundaries and allow the other group to do its job, they both need to work hard to be on the same page. If PM and IXD cannot work together in harmony, then you are destined to have a product that just doesn’t feel right.