Contributed by John Zilch
This past year, our team embarked on a journey to build a better experience for our customers through an updated user interface with better dashboards and data insights. As a Product Manager, I hadn’t taken on a product refresh of this proportion in my career.
Today, with the new changes released to the world, I thought it was a nice time to reflect on that experience. Had I known then what I know now, I would have posted a sticky note on the corner of my computer screen with seven simple yet critical guiding principles.
1. Write stuff down.
Most product people have visions of future iterations in their minds. Maybe they’re fully baked. Maybe they’re a gob of clay that we want to mold over time. When tasked with bringing that idea to life, we were tempted to jump right into mockup-land or begin speaking to customers about the next evolution of the product. Luckily, we were encouraged to write out the mission statement first. Only after defining the “why” could we focus on the “what” and “how”. Why were we refreshing our product and what value were we creating for our customers?
2. Put on your thick skin.
Redesigning your product is a lot of work. There are going to be a lot of good ideas. There are going to be some bad ideas. And we had plenty. The biggest risk to the success of your rebuild is that you don’t receive the negative feedback you need to hear.
After our first design iteration, we were feeling pretty good about what we had built. That is until one of our engineers stopped me at the water cooler: “I heard that the new dashboard doesn’t represent what we do too well.”
I couldn’t possibly unhear that. I could either drown myself in the water cooler or reflect on the feedback. I didn’t fit in the water cooler. He was right. Our dashboard didn’t exploit the value of our services like it should. We eventually scrapped most of what we had built. What came out of that was ten times better than what we had.
(As a side note: Not all negative feedback needs to be heeded. Seth Godin says it much better than I ever could. And this happened a lot during our process. Make sure the feedback is sound and coming from a good place.)
3. Reach out to the right people
Now, that we’ve got on our thick skin, find the right participant for your feedback loop.
An old baseball coach of mine used to say that practice didn’t make perfect, but that perfect practice made perfect. I think that’s applicable here. We could have easily found customers and co-workers who were going to tell us what we wanted hear and validate our assumptions. But what about the opportunity cost? In spending time with these folks, we’d potentially miss out on a chance to hear a fresh idea.
Instead, ask around for thoughtful customers. Speak to customers who cancelled. Find opinionated peers. Show designs to someone who knows nothing about your business or your product. What do these people think? Ultimately, you’re trying to avoid Confirmation Bias.
4. Keep it simple.
“Intuitive” and “Simple” are close cousins. The kind of cousin who could snag a gift from the other at the family Yankee swap without incurring any uncomfortableness or hard feelings.
My first customer interview was with a customer named Catherine. I was pretty excited to speak with her as she fit our core user persona, had great expertise in our field and was a relatively newer customer. I was ready to do a deep dive into analytics with drill-down functionality and modular dashboard capabilities.
Well, as it turned out, Catherine needed two pieces of information. The other stuff was super cool but her essential need was more rudimentary. As it turns out, the majority of our customers needed the same information.
5. The devil is in the details.
While I hesitate to use the word “devil” and then reference my manager, I’ll do it anyway for the sake of this article.
[My first showing to my manager]
Me: Look at all of this! New branding! Enhanced experience! Value-added analytics! What do you think?
Manager: How come you have all these different font sizes on the sign in page?
And that was the summer I reduced the number of unique font sizes across my product.
Product managers ultimately own every pixel of the product. The details – even the small ones – matter. The aesthetics of the product speak to the values of your company, product and people.
6. Be resourceful.
At times throughout the project, we felt we were building an exotic sports car from scratch. To build what we wanted, we’d have to seek out each individual part. We lacked a UI/UX design team. We didn’t have the assets in a previous version from which we could pull. We had data points strewn about in a database our engineers didn’t initially understand. So we meticulously sought out each car part.
Luckily, we were fortunate. We work with a truly kind and talented group of people who like to help.
- Our marketing content manager devoted a lot of time and ultimately served as our UI and branding guru.
- Our engineering team embraced the immense challenge of building various prototypes only to scrap certain components.
- Our one-man dev ops team built us a beta site on short notice.
- Our DBA packaged the data in order for our product to easily access it.
- We had an intern repurpose calculations he had put together for marketing content.
By pulling together across the larger team, we were able to gather what we needed to build and define how we were going to build it.
7. Define “done”.
Once we had a nearly-complete, functional product in a beta environment, our team visited one of our core customers who hadn’t yet been involved in the process. We toured the product together and noted each of her reactions.
Finally, she looked at the team with her verdict. It was the moment we had been waiting for. “I absolutely love it,” she stated. We thanked her. We had reached the end of a long journey. We were victorious. We were bleary-eyed, but excited. We packed our bags and got up to leave.
And then our customer left us with one parting gift: “Oh, I just thought of one more thing you could add…”
There’s always going to be “one more thing” but at what point can you release what you’ve built? This is where the process comes full circle. Review what you wrote down when you started the exercise. What were the goals? Were they met? If so, then it’s time to go live.
Feature image from Flickr Commons
John Zilch is a Product Manager at Dun & Bradstreet NetProspex where he manages the Workbench Data Optimizer solution, a cloud-based platform for Marketing and Sales professionals By building stronger data foundations, Workbench Data Optimizer customers can better achieve their business goals. John has enjoyed building world-class software products for world-class companies such as Intuit, Pegasystems and now Dun & Bradstreet. Follow John on Twitter at @JohnZilch and LinkedIn at www.linkedin.com/in/johnzilch.