How to adopt a lean startup culture: Q&A with Allstate Director of UX and product design, Pradeep Nayar

In a recent webinar, Pradeep Nayar, Director of UX and Product Design at Allstate, explains how Allstate is adopting a lean startup culture and embracing an extreme agile methodology to 'fail fast' and learn from their users to make relevant digital products and services. We had a great Q&A session with Pradeep and included some of our favorite questions below. Enjoy!

At what point do you have users involved in your design flow?

We have users involved as soon as we have something. If we are actually in the early part of the project and we are doing discovery and framing, we have users involved from day two. If we are actually further along in the project, and we are executing in a project, we have users involved every week to every other week. We have users involved all the time through some form of either exploratory, interview style exploratory sessions, or usability testing.

How many users do you talk to on research days? How long do you talk to them? And do you have them in the office?

We try to aim for every week to conduct research. I think where we are right now, we get it to every other week. We do most of our research using remote tools. We don't do as much in person when it comes to deep kind of initiatives.

Now, if it is for a mobile device, we actually do go out and spend time with the users. Sometimes it's five people and sometimes it just an interview. The key is to make sure it's a regiment, that you actually have that as a recurring thing because there's nothing better than having interaction with users to kind of ground everybody on the team.

When formulating this process, how high did the approval process go within the organization?

We get buy-in from our senior executive leadership. But I would say that's not all you need. You need a lot more support from people in the middle and all the way on the bottom because it needs to get propagated all the way down.

What was the most difficult part of the transition as you transition to this new process for each group?

We're dealing with organizational change and organizational shift. So I think the most difficult thing is making sure people understood why they're doing this. When we started off, we started with a proof of concept and there were a lot of people who didn't believe in it but as we started showing success, people embraced it and jumped on board.

How far ahead of development do your UX designs run?

If you are in the execution phase, usually, maybe a sprint or two. It would be nice if you are four or five sprints ahead but you kind of are designing in a vacuum then. We like to be as close to development as possible.

It's a different culture where it's not about putting things over the wall. It's more about that communication and collaboration. Because there might be things that are very design-heavy that need more time. Then it's just a game of prioritizing what's next.

How is lean research different than other research?

Well, with lean research you are not spending a lot of months planning. You don't have a test plan that needs sign-off and gets everybody to buy in. The focus is on making sure you get out of the building.

With us, it's a lot more lean in the form of how we actually execute the research. The leanest part of the research is in the insights that come out of it. We do the research on Tuesday, we synthesize right after the research. And the stories are written right that day. So it's not like you're waiting for somebody to create a fancy deck that needs to be presented to somebody's manager's manager before it gets presented to the team. It's a lot more rapid.

Do you have UX managers and if so, how do they engage in this model?

I have two managers. And the managers actually are overseeing lab locations and are there to provide one-on-one support to a lot of the product designers.

Beyond that I have senior product design practitioners that also provide mentoring support. A lot of times it really boils down to the team being an embedded part of that cross-functional team. And the managers are supporting them in making sure that they have what they need from a career development standpoint and giving them advice and counseling on how to actually move forward.

How do you iterate on a Monday and conduct a user research test on a Tuesday? It seems like there's not enough time.

Usually when you are doing a research study, let say you are doing it on Tuesday, the prior week you have already planned for that Tuesday so you're planning ahead. Now, planning doesn't mean you need to come up with a project plan. It's a lot more rapid. But we already have an idea of what we're testing the prior week. And that's usually a week or two weeks ahead.

Without product managers who owns or represents the business requirements?

The product owner which is essentially the product manager. But the idea of ownership is very different. We use the word product owner, product manager kind of interchangeably here. But the product owner represents the business in this scenario.

What's different though is it's a shared ownership like everybody has skin in the game. The product owner is not going to make a decision without counseling everybody. It's more collaborative and more participatory. So it's a lot more conversational, a lot more focused on getting the team in the same direction. And having the team aligned.

What are some good metrics or reporting to show directors the return on adoption when you move to this process?

When we first did a POC we were trying to see if there any way we could actually show some return investment. We started trying all sorts of things to try to measure that. And then we got to a point where we talked with some of the other individuals that were doing this, other large companies. There's the Ford's and Home Depot's of the world and a few other companies that are actually kind of in this model. And they advised that you may not get what you are looking for because of how different the model is.

So what we did was we started a POC, took a product that was in our old methodology, just estimated as something that would take 30 weeks to do. We got it done in 13 weeks. And it was also tested, validated, and it was the fact that we had it out in 13 weeks that people absolutely loved.

So that speed was one thing that got people excited because that's not how we usually operate. The beauty about it is actually getting something in front of the users sooner, right? And making sure we're not making these bloated features that nobody uses.

So we ended up just doing a POC to prove our case. And by seeing the results that were being achieved by the teams, I think everybody else fell in line. We didn't have to make the case as much.

To move this fast, do you have design libraries of components and guidelines?

We're actually in the process of evolving it. And just like any component library, it's never complete. We had to create a pattern library that's essentially a library of components and pieces that can be used and leveraged. And we are in the early stages of doing that.