Identifying Solutions with The Opportunity Tree

Identifying Solutions with The Opportunity Tree

At Shockoe, we often have prospective clients come to us with a defined idea of what features they want in their mobile app. But more often than not, as we get deeper into the Discovery phase, we uncover truths that make us question if those features are actually the right solution for the problem our client is trying to solve. By then, it may be too difficult for our client to pivot to a new solution, as it would require all new buy-in from their stakeholders. When clients lose sight of why a decision is made, and are far more concerned about the tactical aspect or flashiness of a feature — It’s important to keep the user’s need front and center throughout the process and keep an eye on the overall outcome or objective.

Recently a group of us from Shockoe attended the rvatech/Women conference, and participated in a variety of panels and break-out sessions, such as exploring diversity in the workplace, creating a culture of innovation, and inclusive design. One of the more hands-on workshops was presented by Jenn Atkins, Katie Moriarty, Amy O’Callaghan and Rob Huddleston of Snag, that led participants through the exercise of creating an Opportunity Tree.

The exercise began in a way that seemed very familiar…. our “stakeholder” asked our table (the product delivery team) a simple request– “I need a boat. I need it in 3 months, and I have one million dollars.” We then got to drawing a mock-up of that boat, without asking the stakeholder any questions. At my table, the drawings varied from a mega-yacht, a souped-up fishing vessel, and a solid gold boat paperweight. Snag UX Researcher Katie Moriarty then asked us, “how many of you clearly understood what the stakeholder needed?” And of course, none of us did. So how did we expect that any of our boats would be remotely close to solving the stakeholder’s problem?

1. Outcome

In the world of mobile app development, clients will call us with the same kind of request– although instead of a boat, they ask for features– “I need an app with touch ID.” But instead of turning around and putting that feature in a scope of work, we should ask “why.” Here Snag urges us to follow Toyota’s 5 Whys method developed as part of lean manufacturing:

Q: Why do you need an app that has touch ID?
A: Well, when I use my banking app, I really like that I can just log in with my fingerprint.

Q: Why do you like logging in with your fingerprint?
A: I always forget my password for all these apps, so when I can log in with my fingerprint it just saves me time.

Q: Why does it save you time?
A: I always want to have really secure passwords, so I keep making up different ones for each account that have different combinations of letters, characters, numbers, upper-case, lower-case, and the names of each one of my pets and children. I also never write the passwords down, so how am I supposed to find them quickly??!

Q: And why do you need to log in so quickly?
A: Because if I can’t log in, I always just give up and close the app. I don’t have the patience to go through a long process to reset my password. And I don’t want our users to give up without being able to use the app.

You get the basic idea. By interviewing the stakeholder or client and listening to their responses, you start to get a sense for the desired outcome. So in this case, the desired outcome is not “an app that does has touchID.” It instead is “To decrease user drop-off during log-in by giving users an easy and fast way to log in.”

The desired outcome now goes at the top of The Opportunity Tree.

2. Problems into Opportunities

The next step of the exercise is to start identifying problems so that you can invert them to create opportunities. In the workshop, we did this by interviewing our stakeholder, but this could also be achieved in user research as well. The interview questions were framed around the outcome, and the stakeholder’s feelings around it. “When you think about achieving “X”, what worries you the most? What problems do you see personally?” The group furiously detailed each problem on a sticky note, and then organized them at the end of the interview. Certain themes emerged quickly, and we were able to craft three problem statements that covered all of our stakeholder’s concerns.

Now using our app example, problems might include:

  • I can’t remember my password.
  • I hate when my spouse can’t log in under our account because he doesn’t know the password.
  • I want to be able to get into the app right when I need it — I don’t have time to go through a whole log-in process.

Problem statements are now inverted to become opportunities. Each opportunity is in the voice of the consumer. So the problems above might turn into:

3. Solutions

Finally, we arrive at the solutions, or in our case, features. We now can brainstorm individual solutions that can ladder up to each opportunity. In our exercise, we quickly narrowed down to 2-3 solutions per opportunity. This gives our stakeholders a way to look at potential solves and weigh the value to the consumer, against the cost of the effort, and decide what’s worth moving forward with. In our app example, by doing this exercise our client may decide that no secure information is in the app, so a full authentication process isn’t necessary. And for their consumers, it’s more important for them to get in and use the app quickly than to be logged in.

At the end of the workshop, when we looked back at our outlined solutions, Katie asked us again, “how many of you clearly understood what the stakeholder needed?” And this time, all of us raised our hands. We were confident that the solutions we landed on would meet our stakeholder’s needs, and achieve the desired outcome.

By using an exercise like The Opportunity Tree in the initial sales process, clients and mobile app developers can be sure that the solutions they will be developing and validating all lead back to the overall desired outcome, even before a Scope of Work is signed. This simple process allows us to get to the root of the problems we’re trying to solve when sometimes our clients have trouble identifying what those are. So that by the time the product is ready to be deployed, we can all be confident that we released the right set of features to deliver the most utility to consumers, and business value to our clients.

Rebecca Thompson

Rebecca Thompson

Project Manager

Rebecca has over 10 years of production and project management experience in advertising and tech. She has led numerous national multi-media campaigns including television, print, out-of-home, radio, digital, social, and PR events. Rebecca approaches project management with three goals in mind: to keep the process efficient, team members happy, and the work cutting-edge and award-winning.

From Creative to Tech: 5 Lessons for Mobile Development Project Management

From Creative to Tech: 5 Lessons for Mobile Development Project Management

shockoe-project-manager-Rebecca-mobile-development-project-managementMy journey into Mobile Development Project Management was almost accidental. I started my career in television production, first as a producer on a reality TV show and then jumping into production at a large advertising agency, helping to create television, radio, and video projects for national brands. But after six years of production, I started gravitating more towards the internal management of teams rather than organizing shoots and productions. I decided to give project management a try, and from the minute I felt the warmth in my heart of seeing my client’s multi-media campaign scheduled out across all deliverables, I knew I was home.

When I made the jump to a tech firm six months ago, I discovered several stigmas placed on project managers at creative agencies:

  • They don’t know agile, having worked in a decades-old process that is viewed as slow, clunky, and requiring several layers of approval.
  • They’re only used to working on large, expensive projects, and are unable to follow a tight budget.
  • They’re “snobs” if the work can’t win a snazzy industry award that looks good on a shelf, they’re not interested.
  • They don’t know digital or tech, and they can only work on traditional media (TV, radio, print).

But while there’s some truth and mostly fiction in all of these stigmas, I believe that my experience at that large, clunky agency has given me important lessons and ideas that I incorporate into my mobile development project management on a daily basis. And as more advertising agencies move into 2018 and beyond, agile is becoming more than just a buzzword; consultancies must incorporate more SDLC (Software Development Life Cycle) mobile project management techniques in order to stay competitive and meet their clients’ needs.

With that, here are five lessons I learned that can be helpful to project managers and team leaders in advertising/marketing and tech:

1. Process should help the work get out faster, and evolve and improve it over time
Agile has become something of a buzzword in advertising, and for good reason. Clients are getting frustrated with the time and cost it takes to get work done. But consultancy creatives have several fears about the agile process: that you can’t quantify the time it takes to get the “big idea,” that clients won’t be able to see work in progress throughout and envision the final product, that daily stand-ups would become too much of a time-suck, and that traditional teams should be structured as a copywriter and art director. A large hurdle for an advertising consultancy to get over is to view the work as an evolving piece, and not a finished product. Sometimes that means releasing something to the client or the public if it’s not finessed to the nth degree, or if it has minor bugs. If you’re constantly updating, engaging, and storytelling, then the focus is more on the brand’s journey over time, and less on one 30-second TV spot. Consultancy teams would also benefit from the structure and accountability that a daily stand-up can provide. Responsibilities are made clear, each employee is accountable for the progress and completion of their own work, and the small team is united in their singular mission of getting the work done. And while Project Managers in both industries keep a full list of functionality or deliverables, tech PMs have more of a voice around Sprint Planning, and work with their clients and team members to determine priorities around features, and keep a fluid backlog of “nice to haves” depending on time and budget.

2. Design should improve the experience, not just impress other industry folks
Software Development Life Cycle Mobile project managementAwards are a necessary evil for any consultancy. They’re motivating for employees and serve as PR and sales tools, attracting new clients and making them aware of the consultancy’s work. But one criticism of a creative consultancy is that work is often done for the sole purpose of winning an award, and not serving the consumer. Yet tech companies may often lean in the opposite direction, where design is sacrificed at the expense of functionality and performance. There is a lesson to be learned from both. There is always a place for impeccable design, but its end goal should be to improve the user experience and solidify the consumer’s impression of the brand. As a project manager, that means involving UX/UI designers and developers throughout the lifespan of a project. My most successful projects have started in a room where a designer and developer are both throwing ideas up on the board, and continue collaborating on functionality, navigation, and UX throughout the process, even in QA. But that’s not meant to undercut the importance of a developer because all the smoke and mirrors in the world can’t hide something that doesn’t actually work. This is why in the agile process, we’re not presenting a PDF to the client, we’re presenting a functioning piece of technology. The code isn’t just the “back end” it’s as much of a client-facing deliverable as a design presentation and needs to be as clean, thorough, and documented as the slickest consultancy deck.

3. Strategic Planning can set a foundation for development too
The best advertising campaign is built upon a solid strategic foundation, and a mobile app or tech project should be no different.Functionality shouldn’t be added just because it’s a hot trend– it should make sense for the overall brand and their consumer, and deliver on a business problem the same way a piece of advertising would. One takeaway that a tech company can glean from a creative consultancy is the importance of a creative brief that’s rooted in the overall brand strategy. If the design is always driven by strategy in addition to the normal technical requirements, your projects will never feel like just a string of new functionality with no big picture in sight– which is frustrating for UX/UI designers and developers alike. While sometimes our clients in IT aren’t privy to the marketing plans and decisions of their brands, it’s our jobs to help them create a strategic plan and roadmap that bridges that relationship and creates consistency across all platforms.

4. Saying “Yes” doesn’t mean “Yes, right this minute”
Mobile Development AgencyIn a company meeting recently, our COO Alex was answering questions about timesheets, and stated, “Your nights and weekends should be your own.” I was immediately shocked and felt like applauding (ok maybe I did a little bit). That a statement like that would be shocking speaks to the culture of creative consultancies– you’re expected to be “on call” at all times, and you almost wear your late night and weekend work like a badge of honor. But why? I admit I’m still a bit stumped on this one. Could it be that creatives maintain that conception is not a science, and they can’t predict when lightning will strike? Or that good ideas don’t come until 3 a.m.? Or that marketing clients operate on faster timelines, with emergencies and last-minute media placements popping up quickly? Either way, I have seen some differences after working at a small tech company. UX/UI designers, developers, and project managers all employ “heads-down” tactics that help them to make better use of their time during the day. Also, daily stand-ups and using tools like JIRA and Slack help teams keep tasks prioritized and get work done quickly.

5. But saying “Yes” isn’t a dirty word either
Mobile Development Project Management Creative and Tech One frustration I hear about project managers in IT and tech is that whenever a new idea is raised, the first answer is “No, it’s not in scope.” But if there’s one thing I’ve learned from being an consultancy producer and project manager, it’s flexibility. Saying “yes” is now innate for me, but how do I make sure that we’re protected as a company and not giving away work for free? It’s still a tricky line to walk, but by ensuring my estimates have room for any bugs or issues that naturally occur in development, I can give us and our clients enough space to get it right, not just done. At that point, a new ask from my client begins a conversation: Is this the right piece of functionality for this release, and will the timing work? Will it make this release that much better, that it is worth the extra hustle? With those questions answered, now we can address the budget: How are we doing overall on our hours? Do we have room to add in extra work, or would this addition cause us to go over? By treating a new ask from a client as a conversation and opportunity instead of a disruption, we can reach the goal that’s shared by creative and tech project managers alike: to create work that we all can be proud of.

 

Note from Editor: 

Our team is all about sharing our “lessons learned” and techniques, here are a couple of other blogs that we think you may find interesting:

Ensure Success with the Right Mobile App Delivery

4 Tips in Designing a Retail Inventory Management App

5 Ways Shockoe Supercharged Mobile Workflow

3 Tips to Start Using Motion in Design