Iterating on digital products is a fact of life, but updating your existing app doesn’t have to be a fraught process.
This week we talk to our COO Joana Lehman about the Discovery process, testing as a customer service opportunity, and the best way to keep up team morale. (You can read Part 1 here.)
What kind of questions do you ask during the Discovery phase?
Everybody’s first impulse during Discovery is to want to know everything in advance, all possible outcomes and all factors that will influence the update.
We’re just super-inquisitive all the time and don’t assume that everyone knows everything or even understands everything, which is helpful. No one is made to feel bad for asking a question that anybody else might’ve thought was easy to answer.
When we communicate during Discovery I’m always thinking: “How can we make this process as transparent as possible?” It’s all about making sure that we’re all on the same page and seeing eye-to-eye, which is such an easy thing to assume, but may not actually be the case.
Asking about business objectives in many different ways is helpful. Asking everybody what they think the business objectives are is a good place to start, because the variance in answers provides some truth.
- What’s the most important thing about this update?
- What’s the second most important thing?
- What if you couldn’t deliver either of those things?
- Who are your users?
- Why are they going to want this?
- What does this do for you with your business?
- What assumptions are you basing this on?
- How have you envisioned users reacting to the update?
That’s a way of getting at the truth about the user value that you’re actually trying to generate. It helps everybody get beyond prescriptive answers and assumed ideas about what we’re all doing here. If it doesn’t provide any value to a user, what’s the point?
Are clients invariably surprised at what they find during the Discovery process?
Not really, because our Discovery phase is really well-defined. It’s designed to help them narrow down what they want.
Like we said earlier, it’s natural to lead with “I want it all … the sun and the moon and the stars.” During Discovery we’ll say “Okay great, how about we start with the moon?” “Oh, yeah. You’re right. The moon sounds great.”
So the moon becomes phase one, in phase two we tackle the sun, and in phase three you get the stars. Once we start hashing through the existing app and asking slightly tricky questions, more is revealed. Then we can actually understand what we’re building and why.
Is there a common piece of advice you give in the early stages of updating an app?
Releasing a build is just the beginning. It’s like having a baby. Just because you finished it and put it out in the world, doesn’t mean you get to walk away. You actually have to nurture it, iterate on it, keep it up to date, and care about what your users say.
If you don’t put in the work going forward, people notice and the app stores notice. Apple won’t feature apps that don’t get updated regularly, so they don’t come up in search with any frequency. If users request changes and they never happen, they will simply abandon those apps.
So, be prepared to actually invest time and effort after that initial launch. An app needs to be a long-term commitment and if it isn’t, then maybe it isn’t the right product for you to start with.
How do your clients typically view the Discovery phase at the beginning of a project and the Testing phase right before release?
I don’t think testing’s a thing people want to cut anymore, either for time or budget reasons. Lately, I feel like all of our clients really want to put an emphasis on testing because they understand that the quality of an app is basically a customer service opportunity. If something fails, that’s bad customer service and that reflects poorly on a brand.
The Discovery phase at the beginning is tempting to shortcut, again for time or budget reasons. That’s a mistake. Having to scope something prematurely is not only irresponsible on our behalf, but also for them because it’s unrealistic. It’s incredibly difficult to say “Don’t worry, this is a 12-week project” when we didn’t have the opportunity to define goals, talk to someone on the backend, or even establish whether things like the proper APIs even exist. So I think it’s a critical part for us and we try pretty hard to push for it.
What’s the biggest mistake product teams make when they’re midway through the update?
That’s an easy one: ignoring the process. Changing up priorities part way through a sprint is very frustrating to the whole team … on both the client and agency side. It’s okay when it happens once in a while, but when it happens regularly, it’s super disruptive and morale just drops.
Participating in the process is key. Not participating means you’re not really respecting anybody involved or what they’re doing. It’s disruptive and in the end only diminishes the product.
Also, having a clear product manager, or product owner, is critical, because it means there’s at least one person who’s passionate about the project and willing to fight for it. A dedicated PM keeps us honest and ensures we’re doing our best work. They’re the people we want to work with.
How do you advise clients who want to create a long-range iteration plan?
It’s smart to have growth ideas, and it’s nice to think two, four years ahead. But I can’t tell you what the next iPhone is going to do and what cool features the next Google Pixel will have. Not a lot of people can.
Realistically, knowing what you want to do for the year is great. And even then, stuff’s going to come up. Whatever you release in January should affect what you release in February. Because all of those releases affect each other, by the time you get to August you might have a completely different animal.
If you’re setting sensible goals, ones that aren’t necessarily about setting features but more about the number of people you want to reach and how you’re going to reach them, then you should be fine.
The emphasis on feature rollout at fixed points on a calendar can really box you in. It’s common to hear something like “By August we really want to include this specific feature.” But why? What if you’ve met all of your KPIs by then?
Or, what if you’ve discovered partly through the process that people just don’t want the particular feature you had your heart set on. That great audio, video, or chat thing you want to include? Your users sometimes simply do not care, so you need to be flexible enough to scrap that feature and move on.
Joana Kelly is Chief Operating Officer at Small Planet, where she helps teams create award-winning mobile products for clients like Disney, NPD Group, and Planned Parenthood.
Her work has earned the Communication Arts Magazine Award of Excellence and the Fast Company Innovation By Design Award, been featured on the App Store and Google Play, and been downloaded millions of times.
Joana has guest lectured at the School of Visual Arts and taught at Parsons The New School for Design. She received her undergraduate degree from New York University and holds an MFA in Design and Technology from Parsons The New School for Design.
