How a Scrappy Startup Mentality Helped This Big Tech Company Focus on its Customers
The risks, rewards, and lessons learned from applying “design thinking” in a corporate environment.
by Chris French
posted on 10-22-2018
A few years ago, I began exploring design thinking, an iterative approach that focuses on customer empathy, challenging internal assumptions, and redefining problems. At the time I was exploring resources from the Stanford University’s d.school, with an eye on improving my product management skills.
I’d already started integrating several design-thinking principles, like “bias toward action” (i.e., “action over discussion”) and “getting out of the building” (i.e., “engage customers as often as possible”). However, I never imagined that this deep dive would turn into one of the riskiest, most rewarding experiences of my career.
Leading the design-thinking charge
Soon after the course, I partnered with Craig Scull, an experience researcher at Adobe, to lead a design-thinking session for designers and product managers. After, we were tapped to apply design-thinking principles to evolve the next new Adobe Document Cloud capability.
To do this, Adobe executives encouraged us to adopt a scrappy startup mentality. We quickly started thinking of them less as managers and more as investors. They were giving us permission to be nimble and think outside the box, something that’s rare at big tech companies — companies more comfortable with large, well-coordinated releases.
We chose to keep the team small, and earn permission to expand as we demonstrated success. It was important for us to take the time we needed to understand the biggest problems facing customers, but we also knew our executives wanted to see results quickly.
With that in mind, our early focus was on speed of learning and demonstrating progress to our “investors.” We decided to measure our progress in four stages: identifying a market opportunity, testing for interest in a new solution, testing for usage, and scaling. Here are some of the things we learned at each stage in our path to developing what would become the new Adobe Document Cloud review service.
1. Focus on speed of learning and be ready to change direction
We knew we had to understand customer needs at a deep level, which meant talking to people who regularly share content for review.
During this step, we looked for people with major hurdles in their review process. We believed that if we could build something valuable for these users, others would also benefit.
Initially we looked at PR teams. We knew they generated a lot of content, relied on feedback to ensure accuracy, and worked under tight deadlines. We also knew for PR it was essential to avoid errors — the accuracy stakes are extremely high.
We reached out to a few people on our PR team at Adobe to validate our hypothesis. We also used the opportunity to test out some of our new design-thinking skills — and immediately discovered we were in the wrong place. While our PR team did have challenges with reviews, they weren’t dealing with the extreme challenges we were looking for. As we learned, their content is relatively simple and they typically work with the same group of people over and over.
Though not what we’d anticipated initially, this feedback helped us recognize some of the factors that lead to problems worth solving: managing feedback among those who don’t usually work together, and content that is more complex than what we found with our PR colleagues. We also learned a valuable lesson — It’s fine to be wrong, as long as you figure it out quickly and adjust.
2. Engage with lighthouse customers and design for “wow”
From here, we got better at finding “lighthouse customers” — customers who not only demonstrate “extreme challenges” but who are confident enough in us that they’d be willing to share insights at each phase. In our quest to find these customers, we began to understand their challenges better, and came up with a wall full of ideas that could help solve their problems.
At this point, we knew it was time to start testing some of these solution ideas. We also knew that Kyeung, an Adobe designer who joined our team, could make beautiful designs that would get us positive feedback. He’s good at that.
But we didn’t just want positive feedback. There was too much at stake. What we wanted was feedback with extreme excitement, feedback we could believe in. We wanted to hear, “Wow! I need this now.”
To get that, we needed to create an experience that would make our customers feel like they were working with a real solution. We didn’t want them to have to imagine how they might like it by looking at static designs. We needed a prototype so they could touch, feel, and engage with it.
We gave ourselves one week to make our first prototype. It was functional enough that our very first lighthouse customer could use it with our help.
As she reviewed, we learned there were parts of the experience she loved and other parts she didn’t. We met with a few other customers with similar feedback. We learned a lot, but knew we had to start over. From then on, we set a goal for ourselves to meet with customers every week. We’d design and build in the beginning of the week and validate with a few customers before the week was over.
By tapping into these customers and using their feedback to benchmark achievement, we increased our confidence that we were designing something valuable. And it helped to maintain the support of our “investors.” We needed our customers to collectively deem the work a success — to say, “Wow, I have to have that today.”
That actually happened — throughout the process our customers actually said those words. The first time a customer said it, though, I was speechless. I also knew without a doubt that we were on the right track.
After getting similar feedback from a few other customers, we were able to generate organizational buy in and pull together resources to start making our new Document Cloud features more functional.
The takeaway from this stage was simple: Don’t accept positive feedback as “good enough.” Spend the effort early to gather evidence that you’re building something customers will love. Move forward only after you’ve done that. At that point, you know you’re onto something.
3. Measure success through usage
It’s one thing to think you’re solving a problem, but it’s another for the customer to actually use the solution you’ve built. With that in mind, we worked to make the service more functional. We wanted a few customers to be able to use our solution to get real work done. It didn’t have to be complete, but it had to be self-service.
Our challenge at this point was to be creative about developing a minimum solution so we could show results quickly. Admittedly, it was barely functional enough to let our lighthouse customers do what they needed to do. It did enough, however, that they could experience improvements over the way they were currently working.
After three months of building and iterating, we were confident that our solution was valuable to a few of our extreme customers. Now it was time to see if it was also valuable to a broader set of customers. We had gathered enough evidence to make the case to our investors for a larger investment in the project. We started building for our pre-release customers.
4. Keep your team equipped with deep customer understanding as you add new members
At this stage we found ourselves with a team of 15 engineers — and the expectation to deliver a production-ready service on a schedule.
Now we were working to meet a specific ship date. This immediately changed the tone and process. It also meant catching new team members up on the prior stages — specifically, customer learnings. As engineers made development decisions, they had to be equipped with the same deep understanding we had after all that time working directly with customers.
To be mindful of their productivity, we focused on efficient ways to facilitate learning. We had success in the previous stage when engineers joined us in customer engagements, but that couldn’t always happen. So we summarized our learnings from each engagement and shared recordings so that they could see firsthand where customers stumbled or failed to find value. We built affinity diagrams and journey maps to help organize our insights in ways that could be consumed quickly, but also bring our growing team closer to the empathy we had developed.
While we were working against tight timelines and the inevitable tension of scaling up, we knew this deep empathy for and understanding of the customer had to be preserved in our process. It would be the difference between the ultimate success or failure of our new service — it was among our key learnings for future design-led projects.
Giving teams permission to innovate and delight customers
Taking a design-thinking approach to developing the new Adobe Document Cloud review service enabled us to think bigger, work smarter, and better deliver on our customer’s needs and business objectives.
What’s more, in shifting our thinking to take the time up front to deeply understand customer challenges, we were able to work nimbly with the confidence that we were building something valuable — something I found completely empowering.
Now, as we launch the new document review service for all our Document Cloud and Creative Cloud customers, I’m a firm believer in design thinking as a way to improve our work, our solutions, and our customer-first mentality.
Read more about our new Adobe Document Cloud review service here. Learn more about design thinking and other creative processes emerging from Adobe MAX on the Adobe blog.
This article originally appeared in Entrepreneur.
Topics: Future of Work, Adobe Culture, Community
Products: Acrobat, Document Cloud