Lean UX Workshop – Bologna, Italy – January 30, 2015

bolognaLean UX: Agility through cross-functional collaboration
The world of software has become continuous. New delivery capabilities like continuous deployment and integration have enabled channels like app stores and the web to provide us with an unprecedented feedback loop. Every time we launch software we can take advantage of this continuous learning cycle to understand who is using our products and services, what they’re doing with them and how we’re meeting their expectations and our business goals. Combined with techniques born out of user experience and design, we have an unprecedented opportunity to build products that truly meet customer needs and help our businesses win.

Leave a comment

Lean UX Workshop – Washington DC – Jan 8, 2015

United States Capitol BuildingLean UX: Agility through cross-functional collaboration

Washington DC, Virginia & Maryland Full Day Workshop with Jeff Gothelf, author of Lean UX

Hosted by ICF International, 9300 Lee Hwy, Fairfax, VA 22031

Leave a comment

Lean UX Workshop – Minneapolis/St. Paul – December 4, 2014

 

Lean UX: Agility through cross-functional collaboration

 

Twin Cities Full Day Workshop with Jeff Gothelf, author of Lean UX

 

Hosted by 3M, 2501 Hudson Rd., St. Paul, MN 55144

Mpls-580x474

Leave a comment

Lean UX Workshop – Phoenix – December 1, 2014

phoenixLean UX: Agility through cross-functional collaboration

Phoenix Full Day Workshop

Dec 1, 2014

Leave a comment

2-day Lean UX Workshop in Stockholm, Sweden – October 22-23, 2014

 

Building a Culture of Innovation: Cross-functional product design and development workshop

October 22-23 2014

stockholm

Leave a comment

Lean UX Workshop – New York City – September 26, 2014

empire-state-building-view-nyc-new-york-manhattanLean UX: Agility through cross-functional collaboration

New York City Full Day Workshop with Jeff Gothelf, author of Lean UX

Hosted by Pearson Education, 330 Hudston St., 9th flr, NYC, NY 10013

Leave a comment

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 | 2 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 | 25 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.

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