The Promised Product Page
In my years as a user experience designer, developer, researcher, analyst, strategist and evangelist, I’ve learned a few things. I’ve mastered more technologies, tools and techniques than you can shake a stick at, and they have all been inestimably valuable to my work, which means, to my customers. Still, and I’m sure it has been said many times before by far wiser people than I, the hardest part of product design is not any of these things. Rather, it’s people, or, to be more precise, managing people’s expecations, understanding and thinking so that the product that everyone is building is the same.
Clarity is critically important, of course. Everyone on the team needs the same information so that everyone can get on the same page. But on its own, clarity is not enough. I have worked on dozens of teams where everyone had access to the same information and everyone agreed day-in and day-out on what we were making. Still, as work progressed, invariably things would begin to go astray. User stories start getting juggled in a way not previously agreed upon. Design documentation shifts in a way that no longer jibes with what came before it, and has already been coded. Developers find they are getting lost on account of dependencies and perceived needs. The product manager is feeling like things are unspooling in a way that is becoming hard to manage. And the stakeholders grow increasinly concerned that the product will not meet their needs upon launch.
Unfortunately, this is very typical. Often, more time seems to be spent on trying to keep everyone on the same page than on their primary work function, which, of course, only exacerbates the problem. Yes, the team has access to the personas, the taks flows, the user stories, the sketches and wireframes, the live demo, and everything else they produce in the course of creating the product. However, that is not enough to keep them on the same page. And that’s a problem.
On a recent project this meandering become so serious that the team had actually created and ditched three working prototypes, dozens of UX documents, and many, many lists of user stories, features, and so on. The project manager and others on the team were losing patience with the project and each other, and those stakeholders with the authority to kill the project were beginning to put pressure on everyone, threatening to cut funding unless a product worthy of the time spent was produced, and quickly.
After too many ultimately unhelpful meetings and conference calls, I felt that maybe, just maybe, my design skills could actually help us solve our biggest problem. It was the only thing was had not tried, and to be honest, none of us, myself included, had even considered. But the more I thought about it, I realized that the one thing we did not have was a single place where all the important information about the product we were building could be brought together in a way that was not only clear, but also inspiring. It had to not only keep us on the path, but also make us want to keep going because we would know that the product we would build would be everything our stakeholders and our users wanted.
Naturally, when words and spreadsheets and scrum boards fail — in other words, when raw information fails to convey the most important messages it contains — we turn to pictures. Data visualization is so effective because we know that one pie chart informs us far more quickly and powerfully than any long list. So, being a designer, I set about thinking of the right way to turn all our shared information into a concise, impactful, and effective guiding document, one that would help us all stay focused on what we were buildling, help us return to the right path when we had to deviate, and help motivate us to continue until we achieved what we set out to do.
And so I came up with…a product landing page. You know what I’m talking about. Just do a search on Google for “landing page apps” and choose “images” and you will see tons of great examples. And why are they all so similar? What is it that they do so well? In short, they show us and tell us, in the most concise and inspiring way, exactly what the product will do, how it will help us solve our problems, what it looks like, and possible even what existing users think of it. It uses high-impact graphics and typography to literally sell us on the product, but also making sure that it is what we are looking for. There are no promises of things the product cannot do or claims that are not true. The landing page does not go into detail about the product features and it only shows us a teasing glimpse of the product itself, but it does the job. It makes us want that product.
Of course, the product we were building did not yet exist. What’s more, this was an enterprise app that would never be seen by the public. There was no need to sell anyone on the product, because all the users would have no choice. Right? Wrong. Every single day we had to sell the product, to our stakeholders, to our future users, and to ourselves. We had to make all these people want this product, or why else would we build it?
And so I set out to create what I have come to call my first “promised product page,” or simply, a product page. It’s not a real landing page. Instead, it is a page that essentially promises to everyone what the product will be when it launches. Mind you, we were only focused on the very first 1.0 release, but we figured, if we can get things back on track and keep the green light lit, everything after that would be far easier.
We already had all the elements to use in the product page. The color scheme was borrowed from some hi-resolution mockups, as were the actual visuals of the app. We listed the main features that had been defined, as well as some technical benefits that the app would deliver. We created testimonials based on our personas. We added a background image that created user context. And finally, we gave it a name and added the overall value proposition as the big pitch.
I ran it past the product owner and manager. They loved it. Honestly, they literally gushed. The product, which currently existed only as a hodgepodge of code, prototypes, lists, spreadsheets, diagrams, wireframes, and all that, was now…real. Yes, it was just a picture, but it was real. I had brought it to life before it actually lived, and clearly, that was a very welcome thing.
We made some changes to the product page, of course, but it became a game changer. Some users got to see it, more stakeholders were show it, and even other product teams took notice. The response was universally positive. Everyone suddenly wanted to see the app, which naturally turned up the pressure on us. But we no longer felt pressued to make something that we could not really “see” as a shared vision. Now, we could all see what we were making, and the pressure was not on account of a threat or danger, but rather due to the excitement that grew around the product. Most importantly, it meant that the stakeholders now knew what they would be getting upon first launch, and because they loved what they saw, we had bought ourselves the time and permission to do what it took to deliver that product.
I’m not sure there will always be a powerful need for a product page on every project I’m involved in. Like all UX documents, it’s value is determined by need, not some predefined set of deliverables. However, the tremendously positive impact it has had on the entire process and on those involved says that we need to do more of this. In a way, it’s like when you put a picture of a sailboat on your wall so that you will continue to be reminded to save for that goal. When you see something, even if just an image, it becomes real. And when it becomes real, ambiguity, skepticism and fear fall away and are replaced by clarity, inspiration, and desire. And that helps everyone.