The other night we had reason to celebrate. Something we’d been waiting on for 2 years had finally come through. We’d worked hard and it paid off. My wife suggested we go out to a steak dinner. Forgetting for a second that I don’t eat beef (hey, there’s always the “surf” half of “surf n turf”) I agreed wholeheartedly, excited about the prospect of getting out after being in the house all day. The conversation quickly turned to where we should go when something struck us — the weather was terrible. It was windy — super windy — cold, rainy and generally a gloomy, fall day. Some of the wind gusts were knocking down branches and loose window screens. We really hadn’t noticed it till then but it quickly threw cold water on our plans to go out.
“What’s in the fridge?” she asked. I quickly scanned the contents of the fridge and freezer and came up with, “Frozen chicken parm dinner.”
“Sounds great!” came her shocking response.
Admittedly bewildered I began the extraction, defrosting and warming up of the chicken parm. It didn’t look good and it tasted only slightly better than it looked. However, sharing that meal on the warm couch, covered in blankets while the wind howled outside turned out to be just as satisfying as a celebratory dinner out.
Why was that?
The reason was the total experience of that unglamorous meal. We were warm, casual, comfortable, cuddled up on the couch celebrating an achievement while the howl of the fall weather was satisfyingly beyond the window panes. We were with family, in our home with no pretension or fanfare. The meal itself — the lowly frozen chicken parm — was the bit player in this scene.
What I learned from this is to rethink the emphasis we put on what we believe to be the highlight of an experience. We love to put emphasis on the “killer feature” of our product or the big perk of working in our organization (ping pong tables anyone?) that we fail to see the bigger context. How does that feature or perk fit into the broader context? Where is it experienced? Who with? For how long? Why? Understanding this context allows forces us to rethink the priorities in our products and in our organizations. Is it about the 1-click check out or is it about being able to get that last minute gift to your partner on a special day? Is it about the Nespresso machine or is it about creating environments that foster organic conversation, team building and camaraderie?
When we start to think of the broader context we realize that, in the right context, a frozen chicken beats a steak dinner every time.
In 2010 we visited Ireland for the first time. My wife and I made Galway our first stop. This was the first time we’d been this far away from the kids so we wanted to make sure our mobile phones worked properly. Sure enough, as these things have a way of working out, we were having problems getting our SIM cards to work and needed to find someone to help us unlock our phones. We took the obvious steps — chat and calls to AT&T back in the US which, of course, failed. We then moved on to the local mobile phone stores. We stopped at the unfortunately named Carphone Warehouse and got this curious response to our query,”There’s a lad who lives above the joke shop. He unlocks phones. He’s on the 3rd floor. Go there.”
Coming from NYC this whole sentence sounded sketchy to us. And what the hell is a “joke shop” anyway? So we kept walking — next to the Orange store and then on to Vodafone. Without fail, the advice came back the same. “There’s a lad who lives above the joke shop. He can help you.”
After a bit more sleuthing, we found the joke shop and, sure enough, 2 stories above that we found “the lad.” He ran a small, very local business based on helping people — local and tourist — deal with minor cell phone problems including the issue we were having.
There are no shortage of mobile phone service providers with physical outlets in Galway and yet, this one guy had found a niche that met the needs of the local population, solved their problems with minimal hassles and was significantly cheaper than the big players. He didn’t advertise. He didn’t do any marketing and his hours of operation were often limited. And yet, there wasn’t much the big players could do to compete with him because he was the simplest and easiest answer to these problems. He was Galway’s “life hack” for minor mobile phone issues. A bigger, fancier or more complex solution had no value to the local population.
When working to figure out if your product or feature idea has the potential to succeed you start off by identifying your target audience and the pain point or need you’re product will satisfy. But that’s not enough. It’s equally as important to ensure that your target audience values your solution as well. As was the case in Galway the target market (locals and tourists with minor mobile phone challenges) existed and they certainly had a problem that needed fixing. However they had found a simple, easy way to solve that problem that was going to be pretty hard to unseat in the short term.
The same goes for your products. Just because they work and solve a real need for real people doesn’t guarantee success. Humans are remarkably adaptive and find ways to deal with problems. Your solution has to clearly and significantly be better than their current “life hacks” for them to value it. And until that happens, they’ll continue relying on “the lad.”
My friend Bill Scott once said at a conference, “Agile doesn’t have a brain.” What he meant by that is due to Agile’s software engineering roots many organizations that have adopted Scrum, XP and similar methodologies have done so through their engineering departments. This has led to the creation of amazing software development departments that are incentivized for the efficient and predictable delivery of high-quality code. These teams write great code. And, perhaps more importantly, they SHIP great code — regularly and predictably. For this they are rewarded and driven to become even more efficient with fewer defects.
The questions that rarely gets asked in these organizations however, are:
WHICH features should we build?
DID we build the right ones?
DID we design them well?
DID we optimize them to achieve maximum value for our customers and our business?
That’s what Bill was hinting at. As implemented by many organizations today, Agile — and its methodologies like Scrum — have no mechanism for determining if they’re building the right feature and whether that implementation is designed well and/or worth improving.
This is where Lean Startup and Design Thinking come in. With an experimental mindset rooted in market-based evidence and user-centric advocacy teams begin to question the validity of their feature choices. This humble approach ensures that the Scrum process churns out features that have the backing of the market (i.e., reality) and not just the gut instinct of an individual product leader or team.
The cadence of agile teams plays nicely into continuous experimentation and learning. Teams can build repeatable, routinized research tactics into their delivery streams. This builds a continuous flow of insight into the product development and delivery cycle as well as further upstream into the decision-making process. Effectively, this puts the “brain” on the agile process. And with a brain we make better decisions.
P.S. – The next post will discuss the discipline required to actually respond to the insight this learning process generates.
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.