The document outlines strategies for planning and executing application development in the context of marketing and digital strategy. It emphasizes understanding the purpose of the app, avoiding unrealistic 'unicorn' ideas, fostering collaboration with tech teams, and focusing on user-centric development processes. Additionally, it addresses challenges related to client expectations, budgeting, and the necessity of adaptability post-launch.

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

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

4. So, what’s a "Digital Strategist?"

5. 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 (efficiency, not ideas)
Tools and Apps
Data Analytics
Innovation Pipeline

6. I’ll share some things I’ve learned about adapting
marketing strategies and creativity to technology
and specifically 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…

7. Liminal Space
7

8. Problem: We’ve always trafficked in known
quantities: finite :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.

9. 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.

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

11. What is an “app”?
11

12. A Tool.
12

13. A Rich Feature.
13

14. A Game.
14

15. A Service.
15

16. A Shortcut.
16

17. Post-Digital Hybrid.
17

18. 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) specific task
18

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

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

21. 1. Question “Why?”
21

22. 22

23. 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 financing 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

24. 2. Kill the Unicorns.
24

25. 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

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

27. 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

28. 3. Bootstrap Yourself

29. 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…

30. 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!

31. 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.”

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

33. 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.

34. 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.

35. Question whether you need to rebuild the wheel…

36. 5. Stop Jabbering and Prototype Already!

37. 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 fix unforeseen flaws that feedback has
exposed
This will help you tighten your cost estimates and get
consensus among developers
37

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

39. 6. Collect The Check

40. 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.

41. Psst…
There is likely no line item in your client’s
marketing budget called “apps”.
So prepare to use creative budgeting (and possibly
sacrifice 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.

42. 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.”

43. 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 financial 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

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

45. 7. Resist Feature Bloat

47. Somewhere between financing and launch everyone
will be tempted to add more flair 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…)

48. 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.”

49. 8. Stop Jabbering and Launch Already!

50. 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

51. It is probably the least of your concerns right now…
but you need to pause and define 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?
Define 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

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

53. 9. Doh! Didn’t See That Coming!

54. 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.

55. 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…

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

57. 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 find, look to blogs and articles from
makers of other apps to get bits and reveals of metrics and
methods.

58. 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!

59. 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!

60. 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!

61. 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!

62. 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

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

64. “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!”

65. “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

66. “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 staffing problem (but constant client revisions
expect lots of conference calls)
*Check the contract, surprise, they
Instant action team (in theory) and own code
expertise

67. “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 find
yourself
*Oh, and check the contract, may own
your code

68. “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 fit 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

69. Thanks.

70. 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