Agile is not a substitution for vision

empty throne

 

In his blog post from 2011, Mike Cottmeyer, an agile consultant and coach, listed off the 13 most common reasons his clients began their agile transformation. The list contains reasons like, “faster time to market”, “early ROI” and “risk reduction and predictability.” My sense is that this spectrum of drivers falls along a timeline that reflects agile’s increasing rate of adoption over the past 15 years. Speculating further (me, not Mike), I would guess that items like “culture”, “morale” and “feedback from real customers” are near the beginning of that timeline with “faster time to market” being the overwhelming driver today. One thing missing from Mike’s list is “to find our strategic vision.”

Poor implementation of Agile along with Lean Startup in the enterprise has led to a rising chorus of critiques lately that these methods are being used as crutches for organizations that lack a strong strategic vision. The critique continued that these processes serve as a substitution for a clear vision using experimentation, iteration and continuous learning to “feel their way through the dark” to a solution (and de facto vision) that works well enough.

It’s worth pointing out the flaws in this argument. 

Mike’s list is over four years old now, but the number one item on there still holds true. Agile, as it’s being implemented today by most companies, is an attempt to make software delivery more efficient and predictable. This may not have been its original intent but that is the primary driver for its adoption in my experience. Lean is a manufacturing philosophy focused on reducing waste through continuous improvement and optimization of flow. Lean Startup is a methodology designed to help organizations learn which solutions stand the greatest chance for success. None of these methods explicitly tells an organization WHAT they should work on at the strategic level. 

Strong opinions about market opportunities and ways to capitalize on them are core to the success of any business. Your corporate leaders are abdicating their responsibilities if they’re iterating their way to corporate vision. This is not the fault of a specific methodology or process. It’s just bad leadership.

[Jeff]

Did you find this topic interesting? Learn more in our upcoming book — sensingbook.com 

Posted in agile, enterprise, lean startup, Lean UX, Productivity, Uncategorized, work ethic | Leave a comment

7 Steps to Giving the Best Presentation of Your Life

 

Jeff Gothelf on stage at ISA14 in Buenos Aires.

Just imagine them all naked.

I give a lot of talks. I’d like to think I’m pretty good at it at this point. But it hasn’t always been this way. Sure, years of playing in bands gave me a level of stage comfort that many must overcome but I was the keyboard player – a sideman. When you’re giving a talk, you’re the front person. In fact, in most cases, you’re the only person – with dozens, if not hundreds, of pairs of eyes staring squarely in your direction. While there are countless articles on overcoming stage fright, I’d like to focus this article on structuring and delivering your talk.

The steps outlined below are the scheme I follow each time I prepare a new presentation. I put a lot of time – anywhere between 40 and 100 hours – into every talk because I believe that conference audiences deserve a great talk. They paid a lot of money to be there and far too many talks fail to deliver. Let’s dig in.

Step 1: Have an opinion
You’d be amazed how many presentations I’ve sat through where the presenter rambled on from topic to topic, pausing only to sip some water while we waited for the merciful end of their timeslot.

Pick a theme. Have a point of view. It can be simple. There is plenty of appetite for 101-level content but your talk has to stand for something. This often manifests in the title of your presentation.

I start by asking myself this question: Why am I giving this talk?

Is it to share some learnings? Is it to introduce the audience to a new concept? Is it to challenge an accepted way of doing something?

Whatever it is, you need to have an opinion.

Step 2: Stay practical
I am not a fan of theoretical talks. I don’t enjoy attending them and I don’t give them. I believe people come to meetups and conferences to learn something new, often to help them do their job better. I always ground my presentations in tactics. You don’t need a lot. Three will suffice but one is also fine if you have enough content to dig into the details of that one thing.

Attention spans are fleeting and the pull of that iPhone vibrating in the audience’s pockets is tough to resist. Be explicit about what’s coming up. “I’m going to share with you today, 3 tricks I use to become a better writer.”

There’s room for inspiration in a practical talk. It often comes in the form of your successes using the tactics you’re sharing. But it’s the tactics the audience came to get.

Step 3: Keep it genuine
Passion for your subject matter shines through at its brightest when you’re sharing stories from your experience. Tell those stories but be humble. Recount the stumbles as well as the wins. Poke a little fun at yourself.

Audiences can immediately sense a genuine presenter. Share a personal story that reveals a bit more about you. Weave that story into your narrative not just to endear yourself to your audience but to show how your experience has helped shape your opinion. As you sit down to write your presentation, ask yourself what personal stories – even old ones – you can share that would enhance the points your trying to make.

Step 4: Write the essay first
This is my favorite tactic. Once I have the topic in mind, a set of practical recommendations and a personal story or two I know I want to share, I write an essay. This essay forms the basis for my story arc. How do I set context? What are the core points I’d like to make? How do my personal anecdotes fit best to enhance my narrative? All of this gets worked out when you sit down and write it out.

Bonus tip: This essay, published on your blog or other site, can serve as a great way to test how well your ideas are resonating. If it sparks good debate, conversation and wide sharing, you’ve hit on something. If not, dig into your readers’ reactions to understand where to bolster your storytelling.

Step 5: Use rich imagery and very little text
Slides are there to support your ideas, not to make them for you. Find rich images to enhance your points but resist the urge to cover the image with words. Any words you do put on the slides should be in large fonts and terse (think: tweetable). If relevant, photos you took of your ideas taking flight are very powerful in driving home the tactics mentioned in Step 2

Also, very important: Avoid fancy animations. Projected on big screens they can make people dizzy (sorry Prezi).

Step 6: Be funny
Everyone can be funny. Yes, even you. Humor is, in my opinion, the best way to ensure your audience is engaged throughout the presentation. You don’t have to do a stand-up comedy routine but a few well-timed punchlines can really make a talk memorable. Self-deprecating humor is always best and shows humility.

Step 7: Practice. And then practice some more
Once the story is written, the slides are done and the punchlines are in place, there’s only one thing left to do – practice. This is by far the most important step in preparing a great presentation. Practicing gets you familiar with the content. It helps you refine your timings and your transitions. It shows you where your storytelling is lacking and where it’s strong. It’ll save your ass when the projector conks out two-thirds of the way through your talk.

Here’s how I do it:

  • First two rehearsals – by myself in my office to the wall.
  • Next rehearsal – to my wife (best critic I have). The measure of success here is if she can stay awake throughout the entire thing. :-)
  • Fourth rehearsal – at the office to my colleagues at lunch. Testing the material in a friendly setting will help you gain confidence in your content and presentation style while the feedback will be honest.
  • Fifth rehearsal – back in my office but this time recording the whole thing. Watch the video. It will hurt but in a good way.
  • Final rehearsal – either by myself or in front of the office colleagues again. At this point you should be comfortable with the material, the flow of your story and the timing of your presentation.

These are the techniques I use to craft a great presentation. They help me ground my talk in concrete content I know my audience will appreciate. They also help me ensure that my delivery comes across naturally, in a tone that helps me connect with the audience. Give them a shot and let me know how they work for you.

What tactics do you use? Add them in the comments below.

[Jeff]

P.S. – If you’re interested in seeing these techniques in action, you should join me at one of my upcoming workshops.

 

Posted in brand, career path, Conferences, Productivity, work ethic | 7 Comments

There is no such thing as a killer feature

chicken_parm

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.

[Jeff]

Posted in agile, design, enterprise, Research, ROI, service design, Uncategorized | Leave a comment

The biggest mistake in product discovery: missing the value

The Joke Shop where the lad lived.

The Joke Shop where the lad lived.

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.

[Tweet “It’s equally as important to ensure that your target audience values your solution as well.”]

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.”

[Jeff]

Posted in agile, design, enterprise, lean startup, Lean UX, Productivity, Research, ROI | 1 Comment

Agile doesn’t have a brain

brain!

 

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.

P.P.S. – If you’re interested in learning how to build this “brain” into your processes join me in one of the following cities for a fun, hands-on workshop: Stockholm, Phoenix, Minneapolis/St.Paul, Washington DC, and Bologna, Italy

[Jeff]

Posted in agile, design, enterprise, lean startup, Lean UX, Productivity, Research, startups, work ethic | 14 Comments

Clients don’t want to buy experiments

chemistryset

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.

[Jeff]

Posted in agile, enterprise, lean startup, Lean UX, Productivity | 3 Comments

Do you really have executive buy-in?

exec-resume-pic-C-level-executive-resume-branding-coaching

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?

[Jeff]

 

 

Posted in agile, career path, design, enterprise, lean startup, Lean UX, Productivity, Uncategorized, ux team, work ethic | 7 Comments

What’s the difference between a business analyst and product manager?

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? 

Business Analyst vs Product Manager

What’s the difference between a product manager and a business analyst?

[Jeff]

Posted in agile, career path, enterprise | 28 Comments

Learn by Teaching

Jeff Gothelf teaching

Me teaching…

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.

[Tweet “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:

Austin, TX – June 10

Atlanta, GA – June 26

Denver, CO – July 22

San Francisco, CA – August 7

Stockholm, Sweden – October 22-23

Let’s learn together.

[Jeff]

Posted in Uncategorized | Leave a comment

It’s not enough to build a culture your teams can “live with”

What did the printer do to you?

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.”

[Jeff]

Posted in agile, career path, design, enterprise, Productivity, ROI | 3 Comments