This is your mission, should you choose to accept it: The zombie horde of product managers is approaching, wielding archaic product requirements documents. They have one thing on their minds ' to turn you into another zombie. You're working on an awesome new product. You have a passionate team and a desire to change the world. What do you do?
Stop the Product Development Outbreak
Join our fight against the zombie horde! We've been working to take back product design with Notable, our product design tool. And we've taken the first steps to embedding our customers deeper in our design process with the tool. Why? The product development model is broken. Product development is built to create factory-style production lines for code. Essentially, product development works like this:
- Product managers hand off requirements to designers.
- Designers hand off static mockups to developers.
- Developers build a feature.
- Product managers test the feature.
- Return to step one.
This is a broken process for a few reasons. Product managers have little ownership of the product ' their job is to move the needle one step every iteration until arriving at the dreaded release date. This critical thinking approach is great for micro-projects, where you have a clearly defined problems. Product design is messy, and requires more of a design thinking approach.
Insert Document Here
The dreaded product requirements doc. Not sure if you should build a feature? Go back to the requirements. Don't know if something is in scope? Go back to the doc. Want to market to a specific segment? Back to the doc we go. The requirements document becomes a crutch that product teams throw at a problem without really understanding how it came to be.
Jelly is a Q&A app that came out in January of this year. It's a simple, and beautifully designed app that allows users to have their questions answered. On the surface it had everything going for it. It's beautifully designed, has a simple and focused functionality, and was created by Twitter co-founder Biz Stone. The reality was that it became some of the biggest failures of 2014. It took the Quora model and turned it into a Tinder experience, and that's exactly how it's being used. It's even doing worse than Path, which should tell us something about how effective it is to be in "stealth mode."
Research and Development is Everyone's Job
The problem with the product development model is the focus on execution. The learning and discovery has been done by a different team than the product development team. At ZURB we're a learning organization, and discovery is everyone's job.
The product development model isn't entirely wrong. It got the internet over the last 20 years to where we are. It's a solid model for clearly defined markets, but few new products live in that space. What's the market for Automatic, the car accessory? How do you define a product like Fitbit? Solving customer problems requires investing in customer conversation.
Who Says You Shouldn't Make Your Customers Think?
When we set out to create Ink, our responsive email framework, we approached the project with a desire to solve email problems. We started out from our own pain points with email ' it was difficult to code and test emails, especially for non-engineering-inclined folks on the team. From there, we started prototyping the framework and blogging about our process for building it. We essentially started the process by having conversations internally, and then continuing to have those same conversations with customers.
Once we had some prototype code ready, we started putting the early versions of Ink in the hands of a couple dozen ZURB fans, and started getting feedback. The feedback was immensely helpful. Not only did we get feedback on our syntax, but also on some of the hacks that we were using to get things styled properly for different browsers. We were able to tap into the collective knowledge of our customers.
Customer Development is Your Antidote, or Machete
These are the torches we're carrying forward in our own fight against the zombie hordes. With Notable, we're working to get more feedback from ZURBians and our customers. It's not always easy. We get it wrong sometimes. We're working to get better at it because our goal is to make it easier for our customers to get feedback as well, through the tools we're building.
Facilitating conversations through presenting work is a large component. In our more than 16 years of product design, we've learned how to make effective presentations to create sparks, and we're creating tools that help our customers, and our designers, create compelling conversations around their design work.
Great presentations are meant to spark conversations with stakeholders in order to solicit design feedback. With this philosophy in mind, we've built different ways of giving and discussing feedback on design work in ways that can move products forward.
The goal of any design critique is to iterate. The feedback designers receive on their work should be actionable, allowing the team to arrive at a solid answer through incorporating this feedback loop.
These are the essential components of embedding customers in the product design process. Presenting design work, collecting and discussing feedback, and iteration are essential to a team that's seeking to solve their customer problems.
Be Part of the Next Big Notable Release
We're really excited about the possibilities of enabling others to do what we do at ZURB, through our tools. We'd love for you to come along as we work to solve these problems for others. We can't wait to get your feedback on what we have in store for Notable.
