Fallon Brainfood x Planning-ness 2010: How To Plan Apps

How to Plan Applications Fallon Brainfood @Planning-ness Conference, Denver Thursday Sep 30 - Friday, October 01, 2010

Hi. I'm Aki Spicer. Director of Digital Strategy Veteran Planning Director Blogger Author User "Ofﬁcer of Good" for Planning For Good Forging standards and practices for social media analytics Bringing planning into the age of participation

So, what’s a "Digital Strategist?"

Simply: bringing grounded creativity to technological opportunity. Computer Artistes Code Monkeys User Insights Big Picture Integration Social Content Strategy Web Entertainment Transactions (ideas, not solutions) Mobile and Everyware (efﬁciency, not ideas) Tools and Apps Data Analytics Innovation Pipeline

I’ll share some things I’ve learned about adapting marketing strategies and creativity to technology and speciﬁcally planning and selling applications. 1. Question “Why?” 2. Kill the Unicorns 3. Now Bootstrap Yourself 4. Find Tonto(s) 5. Stop Jabbering and Prototype Already! 6. Collect the Check 7. Resist Feature-Bloat 8. Stop Jabbering and Launch Already! 9. Doh! Didn’t See That Coming…

Liminal Space 7

Problem: We’ve always trafﬁcked in known quantities: ﬁnite :15s and :30s, 728x90s, Half Pages and Full Pages, Billboards, etc. But this era of social, mobile tools, stunt events, programs, communities and post-digital ideas are unknown quantities. And many agencies are not necessarily armed to succeed.

Problem: By most measures, the classic corporate organization (yours?) was developed in stark contrast to the new entrepreneurial ethos of tech “start-ups”. Yet, it is this entrepreneurial spirit that will move us forward to innovation and success.

Problem: You still likely work in a big organization. And your customer, your client, and your company’s very future demands new approaches...

What is an “app”? 11

A Tool. 12

A Rich Feature. 13

A Game. 14

A Service. 15

A Shortcut. 16

Post-Digital Hybrid. 17

Application=Advanced Functionality. Not solely iPhone and Facebook… Could be a banner or dotcom rich feature Could be a feature add to existing platform or game May be more than code – actual soldering wires… Always a singular (or multiple-related) speciﬁc task 18

Application=Advanced Functionality. Implications: Unique Stafﬁng Expertise Due Dilligence Resource Commitment Distribution/Platform Considerations Usage Considerations/UX Money Client Buy-in 19

So you think you want to build an app... 20

1. Question “Why?” 21

Be critical, harsh even, to get your app idea articulated and differentiated from the thousands that may already exist. “Guess what? This app you guys describe already exists…My work here is done.” “Actually, the app you describe is off-brief and off-brand…Thank you and good night, sirs.” Considers Resource-suck Risk – millions of costly apps die daily Demands creative ﬁnancing in a classic ad budget model Is this just merely an agency or brand manager “Portfolio Hit” or “News Headline?” Competition - on the web, everybody competes against everybody Oh, and App Stores do not approve on your schedules 23

2. Kill the Unicorns. 24

Unicorns look so rad on paper – unfortunately you can never build one. These ideas are silly, delusional, impossible. Spot the unicorns. Kill them. “Um, do you even know how App Store really works, dude?” ”I think I know a guy, lets call him…” “I found a company who does this, lets ask them…” “It costs what?!?” “And the campaign launches in 3 weeks…” Discern “crazy-stupid” ideas from “crazy like a fox” ideas From “no” and “yes, but”…” to “yes, and…” Triangulate your idea against the platforms available Know your customer – what are their tech abilities? 25

“Make Something That People Want.”Paul Graham Venture Capitalist, Co-founderY Combinator 26

Stephen Anderson’s Mental Notes cards offers approachable brainstorm sparks for concepting or detailing your app. “…52 ways to apply the psychology of human behaviour to the design of Web sites, Web apps, and software applications.” Excerpted from Stephen Anderson’s Mental Notes card series http://www.getmentalnotes.com

3. Bootstrap Yourself

Bootstrap Yourself: v. to promote or develop by initiative and effort with little or no assistance Merriam-Webster Dictionary (ish) Ok, I made this up…

No one will save you. Embrace a hustler mentality beyond your classic planning chores – generating insights are not enough. Visionary Lion Tamer Huckster Pimp Evangelist UXpert Oh, and don’t forget your day job, too!

Seth Godin offers a good pep-talk on behaving intrapreneurially to get a project thru the system. “This isn’t about having a great idea…this is about taking initiative and making things happen.”

4. Don’t be a fuckin’ Lone Ranger! Find Tonto(s).

Buddy up with your tech leads, your developers, even orgs outside your walls. Art director and copywriter are not enough – get a team Assess your internal organization’s skillsets…can we really build this here? If not, get outside…don’t be afraid to ask dumb questions and get advice – most tech partners are happy to assess your idea and needs earlier, not later Do we build from scratch? Or do we improve on top of another platform – ie “Why build map tools when there is Google Maps?” Hire a creative production company, a development production company, a start up, or a plain ol’ freelancer? Pros and cons each way… Ownership considerations. Intentions to repurpose, monetize? Buyout/Acquisition? License? Partnership? Freelance? Decide now.

Wherever possible, apply App Judo – build on top of already existing platforms. They have user trust, and they’ve overcome the challenges you want to avoid.

Question whether you need to rebuild the wheel…

5. Stop Jabbering and Prototype Already!

You’re probably debating how it works – stop. Get something down on paper, or even on the screen. Not just the “elevator pitch” anymore Draw napkin/chalkboard wireframe Paper prototyping Map out the step mechanics (10 pages or less) of the app from the POV of the user – what exactly does this thing do exactly? Prioritize and “beat-list” the features – now is it logical Post it to walls and halls and solicit collective feedback Kill more unicorns and ﬁx unforeseen ﬂaws that feedback has exposed This will help you tighten your cost estimates and get consensus among developers 37

Apps ain’t gonna pay for themselves, yo... 38

6. Collect The Check

Don’t sell the app, sell the client’s objectives – frame the pitch according to what your client wants to buy! Do what you got to do – angle the app thru the client’s objective lens! • I want fame and the news headline? • I want pioneer innovation? • I want to boost sales? • I want CRM? • I want to fuel more transactions? • I want insightful listening? Sell clients what they want. So position it differently according to stakeholder needs.

Psst… There is likely no line item in your client’s marketing budget called “apps”. So prepare to use creative budgeting (and possibly sacriﬁce something from your traditional marketing plans – creatives won’t see that one coming). *And cheaper costs will enable client to embrace potential risk and experimentation.

Guy Kawasaki, a serial venture capitalist, advises start-ups to explain their ideas in 10 pages or less. Do what Guy says – no tech tomes here. “…10 slides, 20 minutes, and size 30 font.”

Sell Safe: make the pitch feel real and not risky. Forego the deck when possible and show as layout .jpgs (if it’s a phone ap, put ‘em on the phone) or working “thing” Demonstrate how the core functionality is really possible Leverage the proof of your development partners who’ve already done it (or something similar) Button up your ﬁnancial projections and calendars Comparative analysis and case study learnings Highlight customer insights and statistics Lower your development costs so that price is not a barrier (but don’t lose your shirt, either – easily said, huh?) Stage development in phases so that success benchmarks may unlock later budget and further development

Congrats, you’ve collected the check! This is why you’re hot! Remind folks – cuz sometimes they forget. 44

7. Resist Feature Bloat

Somewhere between ﬁnancing and launch everyone will be tempted to add more ﬂair to the app. Don’t. “What if…” additions only piss off your developers, drives up dev time and costs (and delays shipping) The idea was bought because it is simple, and crisp Tighten and improve without adding more wings and doo-dads – don’t Frankenstein this If you add something, subtract something – maintain priorities Ruthlessly silence the clients and associates who have more to add (remind them of additional cost implications, that typically shuts it down fast) Save these suggests for v2, and prep your clients now for those incremental budgets we’ll need after we launch (Ha! Always Selling…)

Robert Hoekman offers keen guidance on segmenting your “nice to have” features from the “things to build right now”. “…great software…has only those features that are absolutely necessary for users to complete the activity the applications is meant to support.”

8. Stop Jabbering and Launch Already!

Things Fall Apart. Particularly when you’re tryna launch your application. Did I mention before? App Store does not approve on your schedule…good luck with that. QA – it means quality assurance, and you need to allot ample time for it But whose really got time for that? “Dogfood” your project – Google uses internal staff to beta test projects for many hours before launching to public Watch the skies – someone just launched your app before you did. Lets brainstorm our differentiation Overbudget? Got awareness? Just because you build it, don’t mean they will come

It is probably the least of your concerns right now… but you need to pause and deﬁne your app’s success metric now with client. Remember the Kobayashi Maru* – set up the rules of success so that whatever happens, you win. • Not about clicks, the conversations? • #Downloads? • Time Spent? • Passalong? • Press coverage? Deﬁne a mutual success metric that is reasonable – don’t permit unrealistic expectations. Oh, and get developer to tag the user actions you want to track (they will be “too busy” to give a damn, but make them give a damn). *What the heck is Kobayashi Maru? Star Trek Classic / Star Trek Neu? http://en.wikipedia.org/wiki/Kobayashi_Marus.com

Oh, and congrats! You’ve just launched an application! Rain Champagne.

9. Doh! Didn’t See That Coming!

Things change when users actually use it. Go figure. Eyes on user metrics (and comments boards) and adapt fast. Multi-variate testing, Google Analytics (free), Flurry (mobile, free), Fbook Insights (free) – get data. Yes, still Wild, Wild West on metrics standards (particularly for mobile) but do what you can. Turn data into insights, and actions. BTW, you did give users a means to offer feedback? Possible Scenario #1: Runaway Success. You win, client wins, users win. Planner writes Cannes and Effies case studies. It gets much easier next time. Possible Scenario #2: Epic Fail. Client demands accountability. Blame and denials. Planner writes post-mortem with learnings. Stear mea culpas toward actionable fixes. It probably gets much harder next time with this client. Whichever scenario – learn from what happened and apply to future developments.

Planning an Application means piloting the whole process, not just beginning or parts… 1. Question “Why?” 2. Kill the Unicorns 3. Now Bootstrap Yourself 4. Find Tonto(s) 5. Stop Jabbering and Prototype Already! 6. Collect the Check 7. Resist Feature-Bloat 8. Stop Jabbering and Launch Already! 9. Doh! Didn’t See That Coming…

Six Odd Jobs and Responsibilities for the Planner Stuff currently not in your job description that you will be responsible for – just because.

Research/Rationale Nervous clients want to feel safe. They will demand case studies, comparative gap analyses, best practices, user data and trends. This stuff is often hard to ﬁnd, look to blogs and articles from makers of other apps to get bits and reveals of metrics and methods.

Technical Copy Because your typical ad writers don’t want none of this. From user instructions, to FAQs to the “thank you” SMS copy after signing up – somebody has to write all that detail stuff. …and somebody is likely gonna be you sucker!

User (Experience) Flows Developer partners (even clients) will need diagrams and “beat lists” that outline the full user experience. Think “if x, then y”, the details may get maddening, but soldier on for the user!

P/R Synopses Because nobody else in the agency can explain the damn thing, certainly not in 2 sentences…they’ll call you. Write the crisp headline you want to see out in the world about it. Good thing you boiled down the pitch in early exercises! *And hey, your name now appears in the article, collect credit!

Promotional Awareness Doh! “The app needs users ASAP!” You’ll be tapped to “use your social networks” to get users. Tweet it, Facebook it, email it…or Push early for media budget to garner real mass awareness!

Mea Culpa Yes, even if you had nothing whatsoever to do with the app, best believe that when/if it fails, you will be called to help explain it with metrics or any other kind of sorcery you surely have! So best to do this thing right, from the start, so you aren’t bowing before an angry client who will seek accountability. #imjussayin

Advanced Level: Pros and Cons of Development Staff Options Considerations the man doesn’t want you to know.

“Wins” and “Pitfalls” of In-House Developer Trust – got your success in mind Costly to maintain a staff member for every code Convenience – right down the platform hallway Likely to be underwater with other workloads You own the code developed Training Boondoggles – “I sent Ideal for sustainable platforms and constant beta projects my dev to Google Wave Boot Camp and all I got was this lousy tee shirt!”

“Wins” and “Pitfalls” of Freelance Developer Trust – may have your success in Costly overages with revisions mind (promise of future work) and constant beta (prob still cheaper than a company) Convenience – right down the hallway Promiscuous…likely working at You own the code developed another shop down the street if you’re into proprietary secrets Quick injection of expertise to free your in-house devs No overhead to maintain – instantly add the dev you need

“Wins” and “Pitfalls” of Creative Production Company Co-creatives with a vocal point-of- Co-creatives, with a vocal POV – view – think of them like they don’t just shut up and commercial “directors” code Instant credibility when you sell the Luxury rates, those euro-jeans client – “these are the makers don’t come cheap of…” Not ideal for constant beta and Not your stafﬁng problem (but constant client revisions expect lots of conference calls) *Check the contract, surprise, they Instant action team (in theory) and own code expertise

“Wins” and “Pitfalls” of Development Production Company No creative tensions, just the Demands you know precisely what you want and adhere to strict scope of code, ma’am work Fast injection of geek army Overages could get costly with revisions Not ideal for sustainable platforms or Diverse selection of geeks to constant beta projects apply to your problem *Shh, most often, they’re just hiring freelancers that you could ﬁnd yourself *Oh, and check the contract, may own your code

“Wins” and “Pitfalls” of Open API or Start-Up License Canary in the Coalmine – they’ve already Open API still means you have much overcome the tech glitches you’d rather to add to ﬁt your needs avoid They’ve got users (and awareness) you May be so busy doing their own could borrow thing that there is little time for your distractions “Seal of Approval” effect on your app, instills trust *Let’s hope they don’t go under – or get acquired Less work – advance to what’s most important to your objectives They are seeking awareness and opportunity to build with you

Thanks.

Let's continue the conversation. This and other Fallon Brainfood presentations may be found at http://www.slideshare.net/group/we-are-fallon @akispicer #Planningness http://www.linkedin.com/in/akispicer http://www.fallon.com

http://unplanned.com.br	1091
http://culturalfuel.net	753
http://planningness.com	731
http://www.chmkt.com.br	453
http://thecuriousbrain.com	182
http://www.randomculture.com	127
http://www.fallon.com	85
http://www.levidepoches.fr	77
http://bits.tijsvrolix.be	47
http://roboilr.dk	36
http://trendspotting.posterous.com	34
http://www.urbanfox.co.nz	30
http://daniseuba.wordpress.com	26
http://thinkdoer.com	22
http://www.litmanlive.co.uk	12
http://colectivoplanner.tumblr.com	12
http://feeds.feedburner.com	12
http://neilperkin.tumblr.com	11
http://chriscloud.posterous.com	9
http://charles.mcsaatchi.com	9
http://blog.theideasketchpad.com	8
http://www.levidepoches.blogs.com	6
http://socialkind.posterous.com	6
http://michaelbatistich.com	6
http://posterous.com	4
http://levidepoches.blogs.com	4
http://static.slidesharecdn.com	4
http://translate.googleusercontent.com	4
http://rblm.dk	3
http://us-w1.rockmelt.com	3
http://www.litmanlive.me	3
http://amplifyinnovation.com	3
http://thereboot.posterous.com	3
http://randomculture.typepad.com	2
http://webcache.googleusercontent.com	2
http://www.seenitbefore.net	2
http://www.neilperkin.co.uk	2
http://bytes.fallonhotdish.com	2
http://www.netvibes.com	2
http://www.hanrss.com	1
http://localhost	1
http://s13-us2.ixquick-proxy.com	1
http://www.slideshare.net	1
http://www.twylah.com	1
http://spotatrend.blogspot.com	1
http://randomculture.squarespace.com	1
http://chmkt.blogspot.com	1

Fallon Brainfood x Planning-ness 2010: How To Plan Apps

by Aki Spicer on Sep 30, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

47 Embeds 3,836

Statistics

Fallon Brainfood x Planning-ness 2010: How To Plan Apps — Presentation Transcript