Leaving Neo

Reality and Change

Image courtesy of @fakegrimlock

Yesterday was my last day at Neo Innovation. In the last 3+ years my colleagues and I worked to build a consulting company that did more than just deliver powerpoint decks and spec documents. We created a company that built new digital businesses. Along the way we learned how to provide lean startup, agile delivery and design services from an external vendor’s perspective and got to work with some of the biggest brands in the world.

My role at Neo evolved into one of education. I worked with our clients to help them understand and practice evidence-based decision making, cross-functional collaboration and customer empathy. The education business thrived thanks to the help from my partners in crime, Josh Seiden and David Bland.

Eating our own dog food, we had a hypothesis that workshops, coaching and speaking gigs would turn into making projects for the rest of the company. We worked to prove out this hypothesis over the last two years but despite multiple experiments, iterations and yes, MVP’s, we realized it was a false hypothesis. The education business was simply going to be a stand-alone business. With the launch of our second book next year and a renewed focus on growing the impact of that business, I’ve decided to strike out on my own.

I will continue to teach public workshops in cities around the world as well as working in-house with teams as I’ve done over the past few years with great companies like AutoTrader UK, Paypal, Victoria’s Secret, Orange, Danske Bank and many others. I will continue to speak at conferences and meetups as my travels allow. So, in essence, it’s business as usual just under my own brand. While my Neo email address will end shortly, I can always be reached at jeff@gothelf.co and my constant presence on Twitter.

I’m eternally grateful to my Neo colleagues for the amazing fun, learning and achievements we’ve made together. I’ll miss them all.

See you in your city soon.


P.S. In support of this transition, I’m hitting the road in a big way in 2016 visiting 6 cities in Q1 including Paris, NYC, Richmond, Tokyo, Toronto and Denver. You should join me at one of those events.

Posted in career path, design, enterprise, lean startup, Lean UX, work ethic | Tagged , , , , , , , , , , , | 3 Comments

Lean UX in the Enterprise

Jeff on stage at Webdagene, Oslo 2015

Webdagene, Oslo, Norway – October 2015

I’ve spent the past 5 years speaking, teaching, coaching and working with teams aspiring to bring a customer-centric point of view to their product development processes. Some have seen great success. Some, despite strong desire and a willingness to adapt have struggled. The challenges the successful teams have overcome have rarely been tactical ones. They’ve mostly stemmed from deep cultural challenges that manifested in rigid management directives driven by a “that’s how we’ve always done it” state of mind. Unfortunately, the way we’ve “always done it” is no longer working. Creativity, curiosity and uncertainty are the norms in a world of increasingly lower barriers to entry, consumer empowerment and software-driven everything. If I had to sum up the past 5 years’ worth of learnings into the 3 biggest shifts organizations need to make, they’d be these:

  1. Value and reward learning over shipping

Roadmaps, estimates and deadlines are relics from the days of industrial manufacturing. Learning is the currency of innovation. Understanding your customer, their needs and motivations and how well our ideas fit those needs, continuously, ensures we’re always on the hunt for better implementations, better features and better outcomes. Rewarding on time delivery simply guarantees customers get to use the wrong solution sooner. Instead, through continuously evolving understanding of the customer we incentivize our teams to solve their problems, declaring victory only when we’ve objectively measured positive changes in their behavior (i.e., outcomes).

2. Hire for curiosity

Never has hiring been more important and yet, in company after company, I see traditional hiring practices checking the same lists of technical skills they’ve been advertising for years. Programming languages come and go. Design tools evolve monthly. Curious problem solvers are agnostic to tools, languages and processes. They’re always craving the next challenge and have the aptitude to solve it. Yet aptitude is not enough. They must also have the attitude to know they are not infallible. They seek evidence and are not ashamed of admitting they were wrong. These are the qualities modern organizations must encourage. At the end of the day, there’s always a better way to do what your company does. The question is will your org find it, or will someone else?

3. Lead with humility

The concept of humility in leadership is a relatively modern one. Traditional leaders are strong, opinionated and direct with their delegation. It turns out, actually, that humble leaders are the same, with one exception. They admit when they’re wrong. It seems so simple yet it’s immensely powerful. If the CEO doesn’t know everything, then it becomes culturally ok to admit the same thing at other levels of the organization. This opens up debate, discussion and, yes, learning. The agile folks call this “servant leadership” and it’s a culture-defining quality necessary for modern product organizations to succeed.

These are the qualities I help the teams I work with instill into their individual projects and their management practices. In 2016 I’ll be setting out to bring these ideas to even more teams in cities around the world. I hope you, your managers and your teams will join me at one of these public Lean UX in the Enterprise workshops:

Paris – January 11-12, 2016 (a 2-day event with my friend Tomer Sharon)

New York City – February 4, 2016 (hosted by Pearson Education)

Richmond, VA – February 9, 2016 (hosted by SnagAJob)

Tokyo, Japan – Feb 17, 2016 (hosted by IDEO)

Toronto, Canada – March 1, 2016 (hosted by Telus and The Lean Enterprise Meetup)

Denver, Colorado – March 2, 2016

Don’t see your city? Let me know. I look forward to seeing you next year.


Posted in agile, Conferences, design, enterprise, lean startup, Lean UX, Productivity, service design, startups, ux team, workshops | 1 Comment

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.


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.


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


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.


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.

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


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

Agile doesn’t have a 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


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

Clients don’t want to buy experiments


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.


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

Do you really have executive buy-in?


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?




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?


Posted in agile, career path, enterprise | 28 Comments