When Josh Seiden, Giff Constable and I first launched Proof (now Neo NYC) we had a vision for a studio that designed and built meaningful, successful digital businesses for our clients. We would work with agile methodologies and incorporate lean thinking into our process focusing heavily on early experimentation, validation and course correction before committing our clients’ budgets in any one direction.
And then we had to go out and sell.
Client after client meeting ended with a lot of the same thing, “It sounds like a great way to work but I just need an iPhone app.” Reflection after these meetings began to bubble up a theme.
Clients don’t want to buy experiments. And they certainly don’t want to buy failure.
We were leading the charge in our sales pitches with the “fail fast, fail often” mantra essentially tattooed on our faces. Many of the clients we were targeting were large organizations where failure was frowned upon. We were a new, untested agency and our prospects were already taking a big risk simply considering us against known vendors. There was no way they could sell us to their bosses under these conditions. And our close rate reflected that.
Like any good learning organization we adjusted course. We tried new language in our pitches. The extreme end of the language experiment ended somewhere around “risk mitigation.” While that’s certainly something every buyer wants, it’s not a sexy selling point for a vendor. Most recently the language that I’ve been using has been around the outcome of failure – learning. Instead of “fail fast, fail often” I’m leading with “learn fast, learn often.” The vision is to get clients to think about the myriad of directions their product can take and then help them decide on the most success potential by learning fast and often. While this does come at a price of some delivery it ensures that what is delivered stands the best change of success in the market.
The tactics remain the same – experimentation, customer development, MVP’s – as do the outcomes – validated learning, course correction, better products and designs – which is something client do in fact want to buy.
Seven years ago I moved back to the East Coast and took a job at an agency. Before accepting my offer I asked my potentially new boss how much support she believed the agency had for interaction design (they were strong on visual design and content). She replied with a note from the President of the agency claiming strong support and understanding for interaction design and UX as a whole claiming it was fundamental to the business’ success. When I left that job a year later, I found out that it was my boss who had written that note and the President had just signed it. That was icing on the cake. By that point it was clear the UX was not something this agency was deeply interested in.
Recently, someone emailed me a question about a new job prospect. It was a leadership position in a company that was undergoing process transformation and the question was about things to look out for as they entered this new role. The person who emailed me was leaning towards the gig strongly because they believed they had executive buy-in for this transformation and the inclusion of a strong design practice. It was a good question. While there are certainly many things to keep in mind coming into a new role, especially during a time of change, one of the most important is executive support for the change. But how do you know if you really do have the executive buy-in you need to make a successful transition happen?
The two things I mentioned in my response to that email are two of the most important things to keep an eye on. They are instrumental to building a successful, collaborative product development team that values not only great process but great design and engineering.
I’ve pasted my response to the question below:
“It sounds like you’re stepping into an interesting situation and with executive support it has more potential than most transformations to succeed. I would keep an eye on two things though before you jump in:
1. Executive buy-in and understanding of the value of design and UX — if the exec team sees UX/design as polish on a finished product, you’re best off going another direction. It will make integrating UX/design into the lean/agile process very difficult. If building a well-designed, delightful system is not that important to the organization then the great work you and your team will do will often get prioritized down to the point of not shipping.
2. Executive support should be absolute, regardless of the consequences — every exec thinks they need to “do agile” these days but very few actually understand what that means to the way they manage their companies, projects and people. If the org is truly bought in then the individual contributors who are pushing back will have to get on board or leave…and the company should be fine with that. Also, keep an eye out for blanket methodologies like SAFe for scaling agile as they often are not agile at all (note the lower case a) and allow execs to continue doing things the same way while the rest of the org slips into very rigid (i.e., not agile at all) release trains and schedules. These frameworks often discourage learning in favor of predictability and throughput — i.e., all the agility goes out the window. :-) “
Leadership requires an acceptance of change not just at the production level but also at the management level. If you’re wondering if you have executive buy-in ask yourself, in the face of objective evidence, how willing are my managers to change course?
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.