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 read an interesting article titled “Brand Is Culture, Culture Is Brand”, which examined the relationship between the Human Resources and Marketing departments in an organization. The premise of the piece is that, in the new paradigm of business, these two functions are intrinsically interlinked. I agree with many of the author’s points, and this is a principle I’ve always tried to employ in the businesses of which I am lucky enough to be a part.
It has been proven time and again that people prefer to do business with a company they are comfortable with and which provides excellent customer service. In fact, many individuals would prefer to again patronize a company that may have made a mistake, but was diligent and apologetic in correcting it, over a starchy outfit that gets it right every time. This is a testament that the human factor is just too powerful to ignore.
It’s almost a throwback to the era of “mom and pop businesses”, in that customers are searching for that personal attention and warm feeling from the establishments they patronize. Even if you are a large or multinational company, it is possible to establish a great culture and brand that is reflected in your staff. And yes, this matters if your business exists only online.
I feel that the HR function, which is the gatekeeper of an organization, has a direct impact on the culture of the company and the ensuing customer experience. The degree to which HR exhibits expertise and diligence in hiring and promoting energetic, talented, and customer focused people has a direct correlation on company growth and customer relations.
The idea of close collaboration between the HR and Marketing functions makes good business sense for a number of reasons. The employees of a company are the face of the organization. If you think that the company bigwigs and investors have the most influence on public opinion and customer perception, think again. A customer remembers the person they spoke to on the phone, the clerk at the counter, or the technician that came out for a repair.
I especially love the example in the article of USAA-a huge insurance and financial services company, serving military families. They offer a great training program in which new employees read real deployment letters, communications from soldiers stationed abroad, and walk in cumbersome 65 pound backpacks to get a taste of what it is like to be a soldier. This understandably inspires empathy, which comes across in how employees relate to customers.
I’ve always felt that it is critical to have the right people in the right positions, and then let them run with the ball. They are the ones that will build and maintain the company’s overall voice and culture. If you examine the Forbes list of the Top 100 Places to Work, the list is littered with companies that are known for their dedication to employees and the customer experience. Some of the most recognizable are Google, DreamWorks Animation Studios, and Whole Foods. These names are synonymous with a great customer experience.
There are so many options for a customer to choose from that the deciding factor is often the customer experience. This, more than advertising and promotions is what solidifies your brand in the minds of the public. I think that it is a promising trend that businesses are recognizing the power of their front line employees in their overall branding strategy. The marriage of Human Resources and Marketing just may be a perfect match.
I’ll be giving this topic a lot more thought in the months to come, and I’ll report back with how things go!
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.
I am thrilled to see the agenda for Magma Rails coming together. I have a real sense of pride in the fact that I helped start the company (Crowd Interactive) that is putting on the first ever Ruby on Rails conference in Mexico! What’s more is that it really looks like it is going to be a great conference.
Some amazingly talented people will be giving talks there, and I am happy to say that I know a few of them personally. The ones to really look out for will be by:
I am truly heartbroken that there won’t be a live webcast of the conference. I wasn’t able to be in Mexico this year for it, and it would have been nice to tune in! That’s OK. I’ll try to make it out next year. I’ll be looking out for all the #MagmaRails tweets.
Anyway, I am really proud to have played some small part in the rails revolution happening in Mexico. Kudos to all the Magma Rails and CI guys for taking it a step further.
I was fortunate enough to be invited to sit on a panel at the Rise of Social Commerce conference here in the bay area this week. I’ve been so busy lately that I haven’t actually had the opportunity to check out the conference agenda until recently, and I have to say that it really looks like it is shaping up.
There seem to be some great panels and talks throughout the two days. Also, the size of the event seems to be ‘just right’ to me. It seems like it is going to be small enough for really meaningful conversations and networking to take place but large enough for there to be a diverse group of folks in attendance.
True to the social flavor of the conference, everything seems to have a hash tag. The conference can be followed with #RSC10. Each session can be followed via #RSCS1..11 or #RSCP1..6. Also, everything is going to be on a live stream that you can tune into here!
Our panel will be on October 7th at 1pm PST. You can tune in via the feed and ask questions via #RSCP4 on twitter!
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.
Recently, I wrote about how advantageous I feel naps can be, and how thrilled I am that there is some evidence to support what I’ve suspected for some time now. Unfortunately, whether the day is just that hectic, or I’m simply not in the mood, there will be times when taking a nap is just not an option. I also know people who are just ‘not good at sleeping during the day.’
Meditation provides a great alternative when it comes to relaxing and refocusing the brain. Peter Bregman wrote this great article on meditation and how it can be especially beneficial from a professional standpoint. The brain can be a powerful thing, but it will only reach full potential when we use it to think proactively. The problem here is that most of us are caught up in thinking reactively. We are caught up in current events, fires, and other issues that spring up throughout the day.
Thinking reactively slows our pace because more time is spent reflecting on past events and current details. Focusing on these lowers our impact because they aren’t necessarily the most important things we can be thinking about. Worse yet, by filling our heads with so much noise, we reduce the quality of the decisions we make. In a sense, this collection of thoughts can be thought of as our ‘cache.’ The more full the cache is, the more time it takes to process information, and the less ideal the outcome will be.
I’m sure everyone can agree that making critical decisions while under stress is a bad idea. Even if time is not a factor, solid decisions will not be made effectively when the brain is full of noise. The cache needs to be cleared routinely in order to achieve clarity of thought. Meditation does precisely this, by focusing and realigning the mind to a steady and relaxing pulse.
There are many techniques when it comes to meditation, but the common element involves clearing your mind of thought. Most folks say that the best way to do this is to focus on your breathing. By doing so, you accomplish several things. Here are just a few:
After a few moments, the cache will be cleared and the brain will be more relaxed.
I highly recommend taking a few minutes to read Peter’s article so that you see how productive doing nothing can be. I still think taking naps is the best way to do nothing, but meditation is a close second. For me, the only way to clear my cache is to meditate or nap. I suggest everyone do one of these daily. You will be amazed how much more productive you can be by doing less.