In 2009, I was put in charge of designing the NASA App — NASA’s first app ever designed for the iPhone. Their vision was to “deliver fresh NASA content on a daily basis to people’s pockets.”
We all had high expectations — and were still blown away by the response.
The NASA app has been downloaded over 10 million times since we first launched and still gets around 2 million hits per day. It has won several awards, including NASA’s “Software of the Year” Award and the “Exceptional Space Act Award” signed by the head of NASA himself.
Designing the NASA app was a huge privilege. It is humbling to see a product I designed have such a strong, continuous impact. This app was also one of the first products that I ever designed. So, the whole process was a true learning experience. And it taught me several valuable lessons.
Here are my top four takeaways from designing NASA’s first iPhone app:
Lesson 1: Maintaining your product vision is just as important as getting buy-in for that vision
After I got buy-in for the NASA App, a Project Manager was assigned to our team. It has been written about before, but a Project Manager is not the same as a Product Manager. Since my project manager didn’t understand the difference between the two roles and had seniority over me, we fought many battles.
The vision of the app was user-driven. So, I validated my product hypothesis by talking to users and looking at our website metrics — a user-centered design approach.
The Project Manager took a different approach. She saw this app as an opportunity to get more resources for our local center (NASA has 10 local centers). “We should highlight a different mission based on their budget,” she insisted. “This would give the missions more reasons to add funding to this project.” She was advocating for politics-centered design that was divorced from any customer conversations.
She challenged the product vision. And I fought back hard.
To me, this is a clear case of why product vision should drive everything you do as a Product Manager. I had clearly communicated why the vision for this app would achieve NASA’s high-level goals. This allowed senior leadership to see that I was working to help grow the whole organization. And it prevented politics from entering the picture.
We ended up launching a pure product designed 100% for our users — and it was a huge success. Many blogs wrote full articles on the app. The public loved it. And even Apple took notice, too. They loved the app so much that they installed the app on every single iPhone and iPod Touch in all the Apple Stores.
The lesson learned here is that as a Product Manager, your job to advocate for the product vision does not end after getting buy-in or even when the designs are done. You will encounter and interact with many stakeholders during the development process. And many of them will try to dissuade you from fulfilling your vision. As a rockstar Product Manager, you’ll have to stay strong and not forget who you’re designing the product for. Your primary job is always to advocate for what will benefit end users and the business.
Lesson 2: Broken process + wrong tools = 3X delays + lots of pain
We estimated that it would take one month to finish the app. It ended up taking three months. Sound familiar?
Why was our estimate so off? There were two main reasons. The first was straight-up inexperience. Since I was new to Product Management, I was not well-versed in the product development process. I didn’t know how to make wireframes or write user stories. And my lack of know-how cost the team time.
The second reason: I had no idea what the right tools were or how to use them. There were no Product Management online courses nor mentors that I could draw wisdom from. I was very much on my own to self-teach — and there was a lot at stake.
There were no Product Management online courses nor mentors that I can draw wisdom from.
To build the NASA app, I basically delivered requirements using wireframes that I had patched together using Microsoft PowerPoint and pieces of text over email. Here’s an example of what I delivered:
The developer would get the chicken scratches from me, try to guess what I was describing, and build it in code. When he showed me a version on a device, I would give him feedback using more PowerPoint wires and text pieces over email.
It was a painful process.
This led to many communication errors and bugs — which led to even more delays. If I had known the right process and used the right tools, the app would’ve been done in a month and a half instead of three months. I am fortunate that the end result was so successful. But that doesn’t mean I forgot how crucial best practice is.
Lesson 3: Product strategy doesn’t end after launching
I’m sure you know how important it is to be able to defend your product strategy. And clearly communicating it throughout the product development process is a critical milestone. But here’s a slightly different question: what happens when the strategy is not maintained after your product has launched?
Let’s take a look at what happened with the NASA app. Here are side-by-side screenshots of the NASA app “classic” version next to the NASA app “modern” version.
Which one has a better design? In my opinion, the older one does. Here’s why I believe that to be true.
The way that users navigate an app is one of the most important parts of any app design. The classic version of the NASA app uses a Tab Bar, whereas the modern version uses a Tile Menu. The Tab Bar has many advantages over the Tile Menu; efficiency is one of them.
If you are viewing “Images” and wanted to switch to “Missions,” you can switch with one tap. In addition, you know what other main features are available – “Missions,” “Videos,” and “Updates.” The Tile Menu makes navigation more tedious.
If I wanted to switch from the “Images” to the “Missions,” I’d have to tap once on back and then tap one more time on “Missions.” This extra tap may not seem like much, but think about the 10 million people who are currently using the app. Think about how many millions of taps are wasted on a daily basis.
Lesson 4: Adding new features is not always the answer
So, why did the navigation change to a Tile menu? Someone likely deviated from the product strategy after the app was first released. “We want to add more main features!” they probably said. “Let’s show our users where our local NASA centers are located! We can build a new main feature called ‘Centers’!”
Adding “Centers” as a main feature was a mistake. It doesn’t fit with the app’s strategy. The vision of the app is to deliver fresh content every day. When you tap on “Centers,” it shows a map of where local NASA centers are and gives you a link to the website. This might be interesting the first time, but who’s going to use it on a daily basis?
I knew I had to advocate the product strategy before designing the NASA app. What I did not expect was how much a product can change after it is first released. The pressure to “iterate” or “add new features” will always be there. And if you do not stay grounded in what you are trying to achieve, an excellent app can quickly go downhill. So, defend your strategy and guard it carefully from feature creep. This will ensure that your product offers value long after its release.
I am fortunate. I got to design the product of a lifetime early in my career. And the results were more than I could have hoped for.
But that does not mean the process was perfect. The NASA app taught me a lot about how to work smarter — and I have applied those lessons to subsequent projects. The best product managers are always looking for new ways to improve, no matter how successful they are. For me, that’s the most important lesson of all.
Leave a Reply