In my consulting practice I visit many companies. In the younger companies (say, 20 years old or younger) the role of the Business Analyst is often non-existent or, at best, a relic of the “early days.” In these, usually Agile, companies, product managers lead the charge with product vision, ownership, customer development, competitive analysis and product strategy. In older companies (2o+ years) product management is a relatively new profession being added mainly as a response to what these companies are seeing these younger companies do as well as a recruiting tool to gain the attention of younger applicants.
This often leads to significant organizational confusion about the distribution of duties and responsibilities between these two roles. To be quite frank, it’s left me confused as well. Product manager seems to be the modern evolution of the Business Analyst and yet, if you ask a BA I doubt she would agree. I’m at the point now where it’s really not clear to me what the difference is between these two roles. To help clarify my own thinking I put together the diagram below. It’s rough, unfinished and not well thought-through but I wanted to get something down and start drawing reactions from the community.
So, looking at the diagram as a starting point for the conversation, what do you believe is the difference between a Business Analyst and Product Manager?
What’s the difference between a product manager and a business analyst?
Over the past couple of years I’ve shifted away from designing products to designing classes. This wasn’t a conscious transition but when I realized what was happening I was surprisingly pleased with myself. Turns out I like teaching (who knew?). What was also interesting was how much I learned each time I taught a class or workshop. You see, it turns out that the more you teach, the more you learn about your subject matter.
Each class is a bi-directional learning experience. I teach the concepts behind Lean and Agile and the tactics of highly collaborative teams to passionate people who embrace, react and often challenge my ideas. They teach me that my ideas aren’t sacred. They force me to rethink my material in their unique contexts and extrapolate learnings that can benefit a broader group. I get smarter and the course improves.
This year I’ve decided to do a series of public one-day classes in various locations around the US, Asia and Europe. It would be great to see you at one of these classes. I get on a plane tomorrow to teach in Tokyo but there are bunch more coming up:
I suffer from a chronic condition. It’s nothing life-threatening and I am lucky that I have a relatively mild form of it. However, left untreated, it makes day-to-day life quite uncomfortable. I was first diagnosed when I was 22 and for close to 20 years now have been taking one form or another of daily medicine to alleviate the symptoms of this condition. Over the years the quantity and frequency of the medicine has gone down. At the beginning I was taking 9 pills a day whereas today I take between 2 and 4 at most. I see my doctor at least every six months where I undergo a fairly superficial examination, a quick discussion of how I’m feeling and re-authorization of my prescriptions. There’s rarely, if ever, any talk about curing me of this disease. Everything that’s ever been done for me or even discussed by my medical advisors has been in the name of allowing me to *live with* the condition.
Occasionally, I’ll look up recent research trends on this condition. Most of the time, there’s nothing. Why? Because the ROI of curing the disease is significantly lower than treating the symptoms.
This attitude of treating the symptoms, not the cause, is prevalent in many of the companies I work with as well. Symptoms are easy to see and target.
It takes us forever to ship a product!
Employees are leaving!
The competition is killing us!
Sales are down!
When diagnosing what’s going on with their organization, leaders often do exactly what my doctors do — they asses the visible needs of the company and prescribe a course of action meant to quickly cure the symptoms. They adopt “Agile” to create the perception that product is shipping faster. They offer a change of project or a trip to a conference to convince restless employees to stay. They ramp up marketing efforts to drown out the competition’s superior product. They organize sales competitions or worse, cull staff to motivate the sales team. All of these activities are focused on achieving an immediate, surface-level sense of improvement. They’re treating the symptoms.
Years of user research practice have taught us that these surface-level pain points are known as expressed needs. They’re the easily uncovered pain points of the organization. As a leader you can throw short-term fixes at these problems hoping to cover up the symptoms but they’ll just keep cropping back up.
This isn’t a new or novel finding. It’s been happening forever and yet, very rarely does it get better. Why is that? Because digging into the cause of the symptoms — the implied and ultimately latent needs of the organization – will reveal the true origins of these issues — corrosive culture.
Changing culture is messy. It’s costly too. A drastic shift in culture will push some people out and may delay some product launches. Most of all, it requires hard work — the kind of work that doesn’t yield an immediate ROI. It’s easier to get the organization to *live with* its symptoms than to cure it of its core cultural ills. The shortsighted outlook is that there is no guarantee a new culture will yield a more productive, innovative and engaged staff. Expending energy on culture cures that may fail is seen as a waste. The longsighted view is that without a fundamental change the company will never exceed its current best and will ultimately suffer an exodus of talent, reduction in quality of output and slipping market share.
Take the time to research cures to your company’s symptoms. The ROI of that work will manifest over time as engaged staff, better products and higher profits. It won’t be immediate but you’ll be creating a workplace your teams can more than “live with.”
When it comes to cult classics, few movies have created a legend on par with This Is Spinal Tap. This 1984, Rob Reiner mockumentary follows the fictitious band Spinal Tap from its humble roots through its meteoric rise to success and then back down to Earth. Along the way they contributed some of pop culture’s most famous and funniest moments, one-liners and memorable movie quotes.
What’s even more fascinating is that, as you break down the movie into discrete skits you can begin to attribute broader significance to the seemingly for-laughs-only ridiculousness of the band’s antics. In this article, I’ve taken 11 (naturally) key moments in the movie and applied them as lessons in product development. Here we go…
1. “It’s a trilogy really…”
In this scene, Nigel Tufnel (played by Christopher Guest) explains to Rob Reiner that he’s working on a new piece. Reiner remarks that it’s different than what the band normally plays as Tufnel goes on to explain that it’s not just one song but part of a trilogy. If there’s one thing that every maker learns eventually it’s that focus is key. Trying to take on too much from the outset often ends up in miserable failure. In this case, Nigel is set on creating a trilogy yet he’s barely written the beginnings of the first part. As you set out to build your next product, pare down your focus until you’re working on one thing. Make that one thing the best it can be before expanding it to take on broader responsibilities. Don’t write the trilogy before you’ve written the first song.
2. “It’s called ‘Lick My Love Pump’”
As the scene above progresses, Nigel tells Reiner the name of the trilogy – Lick My Love Pump. The name immediately gives a sense of what this musical masterpiece is going to be about if not drawing offense first from its target audience. As you build your product, pay special attention to the name. It may seem innocuous at first but the name of your product conveys expectations that you then have to meet with your product experience.
3. “…don’t even look at it…”
Nigel loves his guitars. One of them is so special that he instructs Reiner to not only avoid touching it but to avert his eyes from it. This is his shiny object. The thing that keeps him from focusing on his main goal to write this new trilogy and ensure the band’s ongoing success. As you build your product, you too will come across these shiny objects. They’ll tempt you and steal your attention if you let them. In the end though, they will not help you build that one great product. Indeed, take Nigel’s advice and “don’t even look at it” until you’ve nailed your primary goal.
In this scene, the band attempts to create a life-size replica of Stone Henge on stage while little people dance around it. However, the specifications for the replica are misunderstood since they are written on a napkin by hand. The final product ends up being 12 inches tall instead of 12 feet tall making the little people appear to tower over Stonehenge as opposed to being overshadowed by it.
Communication is key in product development. Sometimes that communication takes the written form. In those cases, it is imperative to be crystal clear about the requirements of the product or service. More often, it is best to communicate face to face. Talk to your colleagues. Understand their needs and their vision. Help them achieve that by ensuring everyone on the team is clear on what’s required and what would make the product a success.
5. “…none more black…”
In this scene, the band sees it’s new album cover for the first time. They’re in awe of how black it is and declare it the epitome of black stating there is nothing on Earth that is “more black” than this album cover.
They were proud. They had a vision and they sweated the details. Do the same with your product. Often, it is those details that you work so hard to preserve that make the heart and personality of your product. Ensure at least some of them make it in.
6. “…miniature bread…”
As part of their catering the band receives small bread. They struggle mightily to make the bread fit the rest of the sandwich components only to lash out in frustration at the lack of sandwich part coordination. The bread clearly failed to meet their expectations and the needs of their activity.
Make sure you understand your audience and their needs. The product your make for them should fit in with the rest of their related activities. It shouldn’t force them to rethink the way they’ve always performed certain functions. If you design your product to seamlessly fit into existing workflows, it stands a much greater chance of success.
7. “…he just blew up…”
Spinal Tap struggled to maintain one person on the drums. Through various accidents, tragedies and unexplained phenomena each drummer in the band met an untimely end. This never phased the band as they transitioned from drummer to drummer.
Your team as well must be ready for personnel change. It is inevitable. People quit, find better jobs, get fired or simply move on. It’s a fact of life and one your team must be ready to recover from quickly. Keep knowledge repositories in a centralized, updatable location. Ensure no one person holds information in their head that could cause your venture to fail. Keep knowledge repositories current so new team members can get up to speed quickly.
8. “…I’m kind of like lukewarm water….”
With David St. Hubins and Nigel Tufnel as the most prominent members of the band, Derek Smalls had to figure out his role on the bass. In this clip he recognizes that not everyone can be the frontman in the group and that his role is to live somewhere between these two spotlight-seekers. What he also realizes is that this role is fluid and morphs from song to song as the band evolves. Sometimes he’s closer to the front, where in other situations he has to hang back and drive the groove.
You too need to recognize your role on the team and ensure you’re giving enough support to the current person who needs it the most. Sometimes, you’ll be that front person, but if you’re not ensure that you’re adjusting your role to support the rest of the team. This will require you to be aware of everything that’s happening and utilize various aspects of your skills as appropriate.
9. “..St. Hubins…the patron saint of quality footwear…”
David St. Hubins struggles to make his last name meaningful in this clip until he realizes he can just, essentially, say whatever he wants. And so he does attributing his last name to be the patron saint of quality footwear. While this may sound ridiculous what David has done in this scene is give his name a label that means something to his audience.
You need to do the same with your product. The product may, like David, not currently live up to the hype of the attributes you assign to it but it gives you an opportunity to test those aspirations with your target audience. If they like it, you now have clear targets to shoot for. If they don’t, you can adjust your marketing to convey a more meaningful message.
10. The review for “Shark Sandwich” was merely a two-word review which simply read “Shit Sandwich”.
The band’s record got panned by the press. They were crushed.
The reality is that you’ll always have your critics and naysayers. Take them for what they are – a sanity check and a source of criticism. Ensure you’re product is addressing the valid critiques and move on from there. Don’t spend too much wallowing in the sadness of bad reviews. There will always be some. Learn from them and move on.
11. “These go to 11.”
In what has become the most widely known and most classic scene in the movie, Nigel tells Rob Reiner that his amps go “one louder” by having dials that go to 11. This, on its own in Nigel’s opinion, makes them a better band then the rest of the hard rock scene.
What Nigel is actually saying is that his passion for his music can’t be contained by an amp that goes to 10. He needs one more than that to be truly understood. This holds true for your passion for your work. Are you satisfied with going to 10? Or should you always be gunning for 11? The answer of course is that if you want your product to succeed, you should always be pushing for 11, spending the time and effort necessary to ensure your product’s success.
This Is Spinal Tap may seem dated to those watching it for the first time but, as it turns out, it was ahead of its time with its pearls of entrepreneurial wisdom.
The difference between successful teams and leaders and those less so boils down to humility. Specifically, it’s being humble enough to admit they don’t know the answer up front. That simple admission changes the dynamic of the team immediately. It levels the playing field by letting everyone else admit that they’re not confident in their assertions either. Without a single keystroke from an HR database administrator, job titles become far less meaningful. It opens up the team mindset to experimentation in an effort to figure out which direction best solves their business and customer needs.
Most importantly, it centers the team’s conversation around a more important question than, “What should we build?” Instead, the team starts to focus on this question: “How will we know if we’re right?” With that seemingly simple shift, the team is now discussing customers, their needs, behaviors and transactions with the business. They’re discussing what changes they’d like to see in customer behavior and they begin digging into the root causes for the current set of behaviors. The conversation morphs from one focused on output (features, functionality, colors, workflows, etc) to one of outcomes the team has determined as success for the project. It is those outcomes that can then be used as filters for the feature conversation focusing the team around only those ideas that achieve their desired outcomes.
By declaring that we don’t know how to solve the problem up front we completely change the way the team operates. This is not something we’re trained nor incentivized to say. In fact, there are people on our teams in roles paid to “know the answer” to these business problems. This simple step therefore is not an easy one but it’s critical if the team is to truly become a collaborative structure capable of pushing the boundaries of the company’s current product development efforts.
The ceramics teacher announced he was dividing his class into two groups. All those on the left side of the studio would begraded solely on the quantity of work they produced, all those on the right graded solely on its quality.
His procedure was simple: on the final day of class he would weigh the work of the “quantity” group: 50 pounds of pots rated an A, 40 pounds a B, and so on. Those being graded on “quality”, however, needed to produce only one pot – albeit a perfect one – to get an A.
Well, come grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity!
It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.
This story perfectly articulates one of the fundamental Lean UX principles: prioritize making over analysis. Instead of sitting around, debating ad nauseum which direction to go in, what features make sense, which colors perfectly reflect your brand values or which words will get your customers to convert, just make something. It won’t be perfect. It won’t work as well as you’d hoped at first but it will teach you something. You’ll get some feedback, some insight on how building your product can be better and you’ll do a better job the second time around.
Sitting around in meetings debating these things usually means one thing: you don’t have enough information to make those decisions. And guess what? That information is not going to magically appear the longer the meeting goes on. Instead, take a first stab. Make the call and give it a shot. Even if it fails thoroughly, you’ll still learn something.
The 800lb gorilla in the room (Image courtesy of Shutterstock)
2013 saw a lot of discussion around the topic of UX Strategy. In fact, there was at least one conference on the topic and a string of articles. However, all of this activity around a topic doesn’t actually mean it exists.
The reality is that there is no such thing as UX strategy. There is only product strategy.
As a company that makes products, you can and need to have a strategy around your goals as a business and your product lines, as far down in detail as the strategy for each individual product you offer. When we work with clients on new product initiatives, the first thing we do is ask them to think about their holistic product strategy:
Who are you building the product for?
What problem are you solving for these people?
How will you solve it?
How will you attract initial users?
How will you retain users?
How will you make money?
Who are you competing against?
How is your product different/better than the competition?
How will your product look? Behave?
All of these questions need to be considered collectively as a company sets out in new directions. Of course, as any experienced UX professional can see, there are elements of user experience design throughout the answers for all of those questions.
However, to explicitly call out user experience strategy as its own thing falsely assumes that this is something that is not considered in the broader strategic picture. Now I know what you’re all getting ready to say — “that’s exactly why we need UX strategy to be called out and explicitly added to the discussion.”
I would argue a different point — a company has to believe that user experience is part of this broader recipe for success and include it as a continuous part of the product strategy conversation if ux strategy is going to be an influential force.
Design has gone mainstream. Every company wants to be the “Apple of…” something yet very few have taken the time to consider what it would mean to bring design and user experience to that level of quality, polish and internal influence. If the organization is not mature enough in its design thinking (lower case intentional) to invest the time and money required to bring ux design in as part of its holistic strategy, no amount of internal lobbying, seats at tables, new titles, job descriptions nor conferences will change that.
UX strategy is part of product strategy. It is not its own thing. Calling it out as such further isolates designers from their colleagues in “the business” and does nothing to actually drive the value of a holistic user experience into the org’s mainstream conversations. Instead, designers should work to inform a product strategy conversation that considers not only the UX but the business’ and product’s success factors as well.
In the industrial-era model of managing a company creativity was reserved for the executive suite. Only leaders and managers were allowed to determine what the company was going to build and how to implement it. These decisions were then pushed down to the execution teams who took this direction and executed it to the letter. In a known domain with known constraints, market forces and consumer behavior this was a productive and efficient way to work.
In software there are too many unknowns. We have no idea how complex a project truly is until we begin it. We have no idea how the product will be used by our customers. In fact, we have no idea IF it will even be used at all. To dictate a fully thought-out solution from the executive suite to execution teams is a recipe for failure.
Instead, your company should strive to democratize creativity. Take advantage of all the talent available in your organization and task them with coming up with the solutions for your business’ problems. Build diverse cross-functional teams and ensure that the freedom to be creative is distributed evenly – not just to the designers. Let them be creative. Let them try solutions. Let them fail and learn. The products these autonomous, self-organizing, creative teams create will be far more successful and innovative then anything you could have dictated to them.
I spend a lot of time consulting with large organizations grappling with making Agile work as an engineering practice and then expanding it to include marketing, product management and eventually user experience and design. Often these companies have invested not only in training but in full-time coaches dedicated to making sure these new practices stick. In the overwhelming majority of cases, these coaches are very good at building in the rituals and policies necessary for improving the agility and predictability of the engineering organization only.
As any coach will tell you, having only one department work in an agile fashion is far from ideal (this is what’s often called Agile Fall – a hybrid process where the up front design work is done in a traditional waterfall fashion and then handed off to engineering for scoping and prioritizing into iterations). With Lean UX gaining popularity as a solution for integrating design into the Agile process, we are often called in to help figure out how to get the whole team working the same way.
The first people we meet when we arrive are the on-site Agile coaches. Immediately, I can sense their concern. They aren’t difficult to ascertain:
How will this affect the rituals and rhythms I’ve been teaching the engineers?
What am I not doing that they feel there’s a need to bring in another teacher?
I don’t know anything about design. Will this new training make it obvious?
If I’ve not been coaching a holistic approach to agility, will this threaten my job?
I want to allay all of these concerns. I want to bring user experience and design into the Agile process in the most effective way. I want the groundwork you’ve laid as the on-site coach to take root and involve the entire team. Without that, the benefits of iterative design can never be achieved. I want the teams to not only deliver great software. I want them to deliver beautiful, usable software. I want to help expand the Agile values of collaboration and communication to the entire product team. In short, I want to help make you and your teams successful.
Change is hard and often scary. Change in the enterprise is even scarier because it involves changing the way people work, how they’re compensated and incentivized, how they manage (and are managed) and what determines success. Whenever I work with organizations undertaking a significant change — like becoming more agile or building in lean startup principles — I often liken it to a sharp left turn.
The thinking (at least in my head) goes something like this:
- The organization is going along, full speed, in the direction it has always gone, doing things the way they’ve always been done.
- At the helm, someone has made the decision to change the way things get done.
- This person announces this change to their subordinates and the rest of the company and in doing so, metaphorically, turns the steering wheel sharply to the left.
- Many of the employees are hearing about this change for the first time during this announcement and are caught off guard.
- Some brace themselves. Others adapt to the turn. Some go with the flow. And still others are not prepared, don’t want to accept the change and are slammed up against the car window (see the sketch above).
It’s these folks, the ones with their faces smooshed up against the window, that are going to resist change the most. Many of them will not go quietly or willingly and some will not go at all. As an organization, you should be prepared for this churn and the inevitable parting of ways that will come with some of your current staff. These may be people you like, who are deemed valuable or even indispensable* and that’s when, as an organization, you must double down on the transformation you’ve undertaken. In fact, if you’re not losing a few people, the change you’re seeking is likely not significant enough.
*Regardless of how “indispensable” someone may seem in your organization (and I’ve certainly felt that way about former colleagues), remember this quote from Charles de Gaulle:
“The graveyards are full of indispensable men.”
P.S. – The killer sketch in this post was done by my Neo Columbus colleague Chandu Tennety.