LinkedIn Hackday

This past weekend, after a three-month hiatus from the coding world, I rolled up my sleeves to hack once more.  This time the venue was LinkedIn, which invited Silicon Valley interns to lock themselves into the cafeteria of the Mountain View-based professional networking giant for 24 hours, in order to hack on whatever fit their fancies.  (Note: For those uninitiated in computer science circles, “hack” is an endearing term for a hasty but impressive feat of coding.  It has nothing to do with malicious intent – that type of coding is called a “crack.”  The media tends to confuse the terms.)

I arrived at 7pm with an idea that I was set on working on, one which would make the world a better place rather than make money.  The idea came from a challenge lodged by the federal government: to create mobile and web apps to help prevent sexual assault (see the challenge).  My idea was the first step in an ideal app for that purpose: a mobile app that would allow a person in a scary situation to discreetly notify a trusted list of contacts that she was in trouble.

Since I was going solo, I chose a familiar technology – Android – on which to develop the app.  The components were straightforward: A screen that would allow the user to pick her list of trusted contacts, a widget that would live on the Home screen that would allow the user to trigger an “SOS” message, and an “Are you sure?” screen that would prevent accidental SOS messages.  An important caveat was that the widget and the Are you sure? screen needed to be disguised as something else, lest the potential victim be caught in the act of crying for help.  Also, including the location of the user in the SOS message would be quite important.

I had never before built a widget or worked with location services, so I was able to pick up some technical pebbles during the night.  By about 2am I had the basic function of the app developed: It had a widget and an Are you sure? screen, could send text messages with the phone’s raw GPS location, and had a screen for picking out people from the phone’s Contacts app.  Over the next 9 hours, I built out a superior UI and integrated with a geocoder to convert the raw GPS coordinates into a street address.

The result was SOS Widget, a simple but functioning and usable app.  After downloading it, a user would add the widget to her Home screen, at which time she would be prompted to choose her list of trusted connections.  On this screen, tapping the plus sign would take her to the phone’s Contacts app, where she could tap on a contact to add it to her list.  She could add more contacts with the plus sign, or remove a contact by tapping the minus sign next to the contact.  The app pulled the name and photo of the contact to make the list easier to understand.  After completing the list, the user could return to edit it anytime by opening SOS Widget from the phone’s Applications drawer.

 

After choosing the list, the widget, disguised as a weather app, would appear on the Home screen.  Now suppose that the user got into a scary situation sometime in the future.  She could then nonchalantly pull out her phone and pretend to check the weather.  Tapping the widget would open the Are you sure? screen, which was disguised as a weekly forecast.  Tapping the sun at the top of the forecast would send a text message to everyone on the user’s list of trusted contacts.  The message contained emergency text, as well as the street address and postal code of the phone.

Having put the app into a good state by 11am, I took the last hour before the noon deadline to prepare my pitch and demo.  With about 45 teams competing, LinkedIn held preliminary rounds, judged by directors and senior-level engineers.  Perhaps in part because of my app’s uniqueness as the only entry created solely for social good, I advanced to the final round, where I would present to the “celebrity” judges (including the creator of the Java programming language, the founder of AdMob, and LinkedIn’s SVP of Engineering) and to all of the competitors.

I was due up last in the group on finalists, so in anticipation I watched one incredibly talented team after another blow the crowd away with its technical prowess.  There was a web-based Rock Band, a networked capture the flag game based on WebGL, and an intelligent voice-based search engine, to name a few.  At the end, I gave my live phone demo under the reflection of a document projector, and it all went flawlessly.

I knew as soon as I started working on SOS Widget that I was not going to win the hackday.  My idea was much too simple from a technological standpoint – its value lay in its product focus.  But I appreciate the desire to keep hackathons for the hackers; by all means, coders should be rewarded for beautifully-executed code.  At the LinkedIn Hackday I discovered, amongst the awe-inspiring displays of mastery of AI, algorithms, graphics, and hot APIs, that I am no longer a member of that computer science uber-nerd club.  I have moved to the product nerd club.

For more on the LinkedIn Hackday, see the official write-up.

The Innovator's Creed

A project I’ve taken on this summer at eBay is the identification and assessment of innovation activities going on around the company, with the end goal being delivery of recommendations on how to grow the practice of innovation there.  A big part of that has been my conversations with those who have taken ideas from outside of their assigned work, successfully built them out, and brought them to market.

What is fascinating about their explanations of success is that all the cases include a set of principles that were learned along the way.  This set is consistent across the lot of them at eBay, and indeed is consistent with what I found at Intuit when I innovated there, leading me to the conclusion that this set is likely universal, at least across mid-to-large-size tech firms.  In creed form, this is what I found contributes to the success of an innovation project in a tech firm:

1. I will not ask permission, I will just do it.
2. I will have my own release cycles, independent of the rest of the company.
3. I will have a completely separate code base from other products in the company.
4. I will have dedicated resources.  (This can mean 100% on the project or some regular time blocked off, like every Friday or every weekend, which is fully respected.)
5. I will have rapid product iterations, with customer feedback at each iteration.
6. Upon completion of a prototype, I will gain the sponsorship of an executive.
7. When it comes time to integrate with other products, I will leverage the executive sponsor to cut through red tape.

Another angle I’m starting to explore is what role innovation events play.  eBay calls them Skunkworks, Intuit calls them Idea Jams, and LinkedIn calls them Hackdays, but the premise is always the same.  Those who have successfully innovated almost universally deride these events as mere working sessions, not the innovation jump-starters they claim to be.  My theory is that the true value in these events lies in the relationships built, the knowledge gained, and the positive energy captured by the participants.  Thus executives should spend less time trying to convince everyone that x% of the company’s products have come from innovation events than highlighting the number of participants that learned a new API or programming language, or the number of participants that got to experience a new role. (e.g. Product managers acting as marketers, designers acting as developers, and so on.)

How to be a Product Manager

My latest read is Marty Cagan's book on how to be an effective Product Manager, Inspired: How to Create Products Customers Love.  I wanted to pick up a guide to Product Management to get an additional perspective in my internship at eBay.  This book came highly recommend by Amazon reviewers, so I thought I would give it a try.  Cagan is the head of the Silicon Valley Product Group, an organization of current and former senior product executives in tech, where he has been since 2002 after leaving his post as eBay's SVP of Product Management and Design.  Side note: Before picking up the book, I had no idea that it was written by my current VP's predecessor.  The fact made the book a bit more interesting and insightful for me, though.

Cagan presents his view that successful PMs are like CEOs of their domains: They utilize all parts of the business and the technology to move their products towards the visions they have created.  He is careful to distinguish this type of role from what is called "Product Manager" in many organizations - in some companies, PMs are focused on market research and the development of business requirements, while in others, PMs are technical managers tasked with delivering defined projects on time and within budget.  Cagan's PM is both of these and neither of these; he advocates for organizations to have "Product Marketers" who focus on the market, and to have "Project Managers" who work with the technical teams (dev, QA, release management) to get products out the door.  Cagan's Product Manager is someone who sits in the middle of those roles, translating what customers/markets want and need into feasible technical specifications.  As part of that process, the PM must seek to understand customers and opportunities (i.e. have a foot in marketing) as well as communicate those opportunities to, and inspire and lead, the technical teams (i.e. have a foot in engineering).

In short, a PM must utilize marketers, user researchers, interaction designers, product designers, developers, testers, and any other roles available, to get the right product built.  She is the one ultimately responsible for the product (the "wringable neck" as some say), though Cagan highlights the fact that she does not have the power of hierarchy - a PM does not manage these people, so she must influence them using her credibility, which is gained over time with success and clear communication.

Cagan spends a large part of the book speaking to the important interaction between PMs and designers. He argues that designers, particularly interaction designers (those who think about the flow of the customer's interaction with the product), need to be involved near the genesis of a project and must be given the time to design a beautiful product before developers get their hands on code.  His argument is that having the right design is critically important and that the function is all too often relegated to "prettying-up" a product that has already been built.  Also, design cannot happen simultaneously with development (at least on the front-end) since developers must be given clear direction on the flow, look, and feel of the product, all of which come together as one package as opposed to modular chunks.

That leads Cagan to a somewhat controversial proposition: That the tried-and-true PRD (Product Requirements Document) should be ditched in favor of a "high-fidelity prototype."  This prototype, ideally created through the efforts of one PM, one developer, and one designer, would contain all of the meaningful interactions to be in the end product, and would of course contain the look and feel of the end product.  The argument for this method of communicating requirements is that it will save time (by quickly communicating what needs to be done) and will improve quality (by unambiguously communicating what needs to be done).  In that argument is the assumption that PRDs tend to be long and boring (and thus aren't read) and tend to be imperfect translations into words what are supposed to be visual and interactive experiences - using a PRD is like translating a French poem into English then back into French - information is inevitably lost.

While everyone has their complaints about them, PRDs are used extensively at eBay.  I brought up Cagan's high-fidelity prototype idea in a couple of conversations with senior PMs on my team, and I heard several valid reservations:

• Developers may be able to play with a prototype and see how to build the product, but what about QA?  What about the edge cases they need to test?
• A lot of (maybe even most) projects do not involve building a new product from the ground-up, and thus are small, involving one or two developers.  If you're taking a developer to build a prototype for this, you might as well just build the whole product.
• What about non-visual products, like APIs?  In that case a prototype doesn't make sense - you just write the specifications.

It is thus apparent that the prototype method should only be used when appropriate for the situation (visual product with a large team).  Also, it is probably a good idea to do a test run of the method before committing to it entirely (i.e. build a prototype and write a PRD, then see which one the team finds more useful).

In summary, Cagan's book serves as a great guide to someone new to the practice of Product Management as it clearly outlines the roles and responsibilities of the PM and everyone else she must work with to get the right product to the customer.  In my own six weeks of experience at eBay, I have found that Cagan very accurately describes this company's version of the role.  For the seasoned PM, the book offers several fresh ideas for how to better do his job, though he must think hard on which ideas would work well for his own situation.

A Stake in the Outcome

Living in San Francisco while working in San Jose has the drawback of a long, hour-plus commute.  Except in my case, where it’s somewhat of a benefit:  It’s my time to continue my business education while school is out for the summer.  You see, most of the large tech firms in Silicon Valley send buses to San Francisco to pick up employees – you could call it a green initiative, but it’s moreso a tool to attract young talent that prefers city life over the suburban Valley – and eBay is no exception.  So, with each ride in the morning and afternoon, I take the opportunity to work on the list of books my professors recommended to classes for additional insights.

The first one I picked up, Jack Stack’s A Stake in the Outcome, provides a narrative of a company’s journey to create what Stack calls an “ownership culture.”  The company (which he founded and managed), SRC Holdings, began as an employee buyout of a factory owned by a large machining firm, and developed a somewhat democratic management style.  It was one of the first companies to implement an Employee Stock Ownership Plan (ESOP), and it used the plan to great effect in incentivizing positive behavior.

A couple of Stack’s points about creating an effective ownership culture jump out at me:

1. It requires all employees to understand the fundamentals of business.
2. It requires employees to be invested in the business long-term.

The first point relates to a concept he calls the Great Game of Business – effectively, it involves practical business training for all employees by evaluating them based on real business metrics and teaching them what the metrics mean.  For example, a team of line workers might receive a higher bonus if the factory improves its cash balance.  Once the employees understand what contributes to the cash balance, they may find ways to reduce throughput time in order to reduce the investment in inventory, for example.  But even more powerful than reaching for the bonus is the realization of the direct relation of the metric to the health of business, and therefore its stock price.

The effectiveness of that part requires Stack’s second point.  Specifically, he states that employees need to be invested in the company long enough for the feeling of ownership to sink in.  Stock ownership needs to be a long-term deal with employees, not an additional method of compensation.  He expresses his reservations about the route Silicon Valley firms have taken with stock ownership, with options vesting after a year or two:  His belief is that a year, or even a few years, is not enough time for ownership to take root, where an employee feels that he is invested in the business for the long-haul and that his actions have a measurable effect on his business (and therefore his livelihood).  At SRC, stock options typically vest in seven years.

What Stack doesn’t specifically call out, but which I believe is critical to creating an effective ownership mindset, is the requirement of the business to be small in size.  Towards the end of the book, he talks a lot about SRC’s constant search for areas in which to spin off companies, which would create opportunities for new management teams to experience the power of leverage and the power of ownership of a small business.  Without the smallness of size, these effects, and thus the lessons, would be greatly reduced.  This concept is echoed by Clayton Christensen in The Innovator’s Solution, where he states that teams formed for disruptive innovations need to be separated (organizationally and often physically) from the larger business so that they can get excited about small numbers and can be forced to be impatient to generate profits, just as a startup would.  I love thinking about this topic of creating successful innovations from within the context of large organizations, so I’ll be looking for more literature on it.

The First Year of Business School

Standing by the printer in the deserted but usually-bustling student lounge, while I waited for the last pages of the last assignment I would complete as a first-year MBA student, I reflected on what had changed since I rolled a full car load into a swelteringly-hot Bloomington nine months earlier.  What did I really learn in that time?  Had I changed as a person?  Or had the last nine months been a mere vacation from real work – the engineering world, which is what some in the tech culture would believe?

I learned that marketing is the most important and the most difficult part of business (and by “business” I mean everything, including product development).  It’s the most important because without it, both you and your potential customers are blind.  You can build the coolest piece of technology in the world, but if it doesn’t solve a problem people care about or if the right people don’t know about it, you have no business.  Likewise, you can be the world’s best fundraiser, convincing investors that you have the Next Big Thing, but your investors are not likely to also be your customers.  Marketing is the most difficult part of business, not because it is academically rigorous or difficult to understand, but precisely because it is not academically rigorous.  I believe that a large part of the vacation-like reputation that business schools have for some is due to the study of marketing – we watch commercials and read ads from big, successful companies; we learn about writing survey questions; we watch videos of people shopping in grocery stores; and when it comes to making recommendations, we seem to pull something out of thin air and say, “this looks like a good idea.”  The part that makes marketing so difficult is that it’s impossible to logically prove that you’re doing the right thing.  Good marketers are good because they know the tools, know when to apply them, and have an innate understanding of the mindsets of their customers.  Just as sportscasters cannot prove whether or not the Packers will win their first regular season game, good marketers cannot develop logical arguments that will prove their correctness – they just simply get it right most of the time.  And getting it right takes an immense amount of research, insight, and luck.  And that’s precisely why it’s so difficult.

I learned to believe that I know what I’m talking about.  Back in October, I attended a business plan review for a pair of entrepreneurs, put on by the Graduate Entrepreneur Club.  Two second-year MBA’s spent an hour launching pertinent questions at the entrepreneurs, driving the conversation to complex levels and prompting many “we hadn’t thought of that” responses.  I was lost.  It wasn’t that the conversation was beyond my understanding, it was that I knew there was no way I could have carried on such an insightful and valuable conversation with the entrepreneurs.  But just several months later, in my first service rendered as an Innovation Fellow at the Hoosier Hatchery, I sat down with an entrepreneur and talked through all aspects of his business and helped set his direction in a chat that lasted an hour and a half.  I knew that I provided a lot of value because there were many aspects of his business that he hadn’t thought about or didn’t know about, and were exactly the aspects I had been developing an expertise around in business school.

I learned what I was hoping to learn: How to be a successful innovation leader in a corporate setting.  The ideas I read and heard about from Clayton Christensen, Jeff Covin, and Dr. K caused light bulbs to turn on time and time again.  But what excites me most is that there is still much for me to learn in this area, as well as much to be discovered in the field.  I hope that someday soon I’ll be able to offer my own innovation initiatives as subjects to further this research.

Was it worth it?  If I said “no,” I would be admitting that I blew nine months of my life and a heck of a lot of money, but truthfully, deciding to go to business school was one of the best decisions I’ve ever made.  I can now put context around what I did (and can still do) as an engineer, allowing me to understand everything from how what I’ve built interacts with the customer to how team members interact with each other.  I believe it’s that broad mindset that makes the MBA worth it.  And what’s more, I have made great friends and contacts and learned a fabulous amount from the diverse student body at Kelley.

After exiting the student lounge, I climbed the stairs to cross over to the old Kelley School building, passing by plaques with the likenesses of wealthy alumni donors and wondering if I would ever be in such a position.  After dropping my paper into the appropriate box, I turned my mind to the next adventure: a summer of putting my new-found skills to use at eBay, back in my adopted home of Silicon Valley.

The Innovator's Acquisition Solution

Last month I polished off Clayton Christensen's The Innovator's Dilemma, blown away by its simple-yet-paradigm-shifting message: Great companies led by great managers fail when faced with disruptive innovation, not because they lack the necessary management skills to be successful, but precisely because they have the necessary management skills to be successful.  Great managers listen to their best customers and their best investors, and each demands ever-higher quality and ever-higher margins, respectively.  Naturally, great managers thus ignore lower-quality and lower-margin product innovations.  But with continuous improvement, when lower-quality becomes good-enough-quality (coupled with other desirable features) for the worst customers, those customers flock to the new innovation, and the great manager decides to move upmarket to solve for only the best customers.  Then the innovation becomes good-enough-quality for better customers, and they flock to the new innovation, forcing the great manager further upmarket.  This cycle continues until the great manager is left with no customers.

At each step in the cycle, the manager has the same choice: Solve for better customers with a higher-margin product, or solve for worse customers with a lower-margin product?  The correct choice is obvious.  But after so many cycles, the manager ends up with no market.  This is the innovator's dilemma.

In my Strategic Management of Technology and Innovation class, we recently discussed the subject of this very innovator's dilemma.  After class, I approached the professor (Dr. Jeffrey Covin) about writing a term paper on the topic.  He suggested I read Christensen's follow-up book, The Innovator's Solution, which I'm now about halfway through.

The Innovator's Solution recaps a lot of the material from its predecessor, but it begins to add a bit more detail about how to address the dilemma as a corporate innovator.  The crux of the strategy is to treat a disruptive innovation (which can be defined as a product that is not competitive with the category standard (e.g. iPod) on the main dimension of performance (song capacity), but which brings other potential advantages (superior portability), AND which can be improved on the main dimension of performance (song capacity) faster than the demands of the market) as a new and separate potential venture.  When evaluating such an opportunity, a manager should approach it as a seed investor would, not as a manager of an established company would.  If he evaluates the opportunity against other established-business opportunities (i.e. sustaining innovations on established products), he will inevitably choose to not pursue it vis-a-vi the innovator's dilemma.  What's more, the manager needs to pursue the opportunity by spinning off an (relatively) autonomous venture to isolate it from the demands of the larger business.  For example, an established business may have a policy to not pursue accounts worth less than $1 million, but a disruptively innovative product may have to start out with small accounts to gain traction.

And that is the point that interests me the most: How does a corporate innovator effectively create a new venture and isolate it from the main business to allow it to blossom?  In my own experience at Intuit, I was able to watch such a new venture form via acquisition, when the company acquired Mint.com.  I witnessed management first try to integrate Mint into Intuit's existing personal finance business, then subsequently back off and try to isolate it.  I plan to use this situation as a case study to further explore disruptive innovation.

Startup Weekend

This past weekend I was inaugurated into the club that few know about, but that every innovator- or entrepreneur-to-be should want to join.  I experienced a Startup Weekend.

This experience taught me volumes about generating an idea, getting people excited about it, leading a venture team, and communicating value, not to mention practical skills like programming PHP.  Here I recount the weekend as I look back on it.

Friday
On Friday evening, about 70 of us filed into a room in the Purdue Technology Center in Indianapolis.  Hands were shook, introductions were made: About 40% of the room were software developers, 30% marketing manager-types, 20% general manager-types, and a handful were artistically-inclined designers.

Each of us with an idea for a company had 60 seconds to pitch to the masses to attract team members.  I pitched an idea that had struck me two weeks earlier in my Marketing Research class: An SMS-based market research service that would recruit subjects by paying them $0.10 per SMS question that they responded to, and organizations (companies, political campaigns, other market research firms) would pay something like $0.30 per respondent for the service.  The client would get an auto-generated report with the results of their mini-survey within hours, since respondents would generally reply to the SMS immediately, and would get the results for pennies on the dollar compared to other market research methods (Internet, direct mail, phone, etc.).

My idea turned out to be quite popular, and as such there was no trouble forming a team.  The four of us claimed a table in a hallway and set to work figuring out how to get this business started.  It would be hard to find a more diversely-experienced team: a marketing expert with years of experience, a college freshman with self-taught coding skills, an athlete with no technical or management experience per se, but who was excited to be involved in a startup, and me, a trained software developer currently learning this business stuff.

One of our first tasks was the all-important naming of our company.  After recruiting some help in coming up with a tagline ("Text. Earn. Learn." describing the three core components of the idea), we did a massive domain-name-availability search and eventually settled on txtern.com, giving us the name Txtern.  By the end of Friday night we had our domain, a Twitter handle, a Facebook page, and a technical design.  It was smooth sailing!

Saturday
In the morning, after a PR update, we hit the ground running on the technical side.  But it turned out that we ran into a swamp, which led to a wall, which led to a precarious cliffside.  The technology gods were angry with our promising idea, apparently, as we battled with recurring server issues (we changed servers four times), database access issues, and this-is-harder-than-I-thought-it-would-be coding issues.  By 4pm, I was ready to declare this product vaporware and just pitch a PowerPoint on Sunday, and I was irritated when we were all shepherded outside for a forced rock-paper-scissors tournament when I really needed to get that damned Apache Tomcat server installed.

That's right: We were forced into a rock-paper-scissors tournament.  Believe it or not, it turned out to be the saving grace of our day-old company, as it gave us a much-needed break from the grind of constant roadblocks and allowed us to think of a new technology strategy.  It was the best-spent 15 minutes of the entire weekend.

Our new strategy was to build the whole backend in PHP, which, as it happened, neither of us programmers knew.  But since Twilio (our chosen SMS service provider) provided great documentation on usage in PHP, we decided we'd learn it along the way by buddy-programming our way to success.  And it worked: Within an hour, we were adding phone numbers to our database.  Within another hour, we were sending text messages.  And by the end of the night, we could type in a survey question, have it texted to everyone in our database, and record their responses.  Success!

All of this was accompanied by another round of success: An experienced designer and entrepreneur for 30 years decided he wanted to join and help us out.  He provided fabulous ideas, logo designs, and the little "extras" that go a long way in a new business.  I now fully appreciate the value of graphic design in making a new business appear 1) professional, 2) real, and 3) bigger than it actually is.

Sunday
The final day was largely smooth sailing as we integrated the backend technology with the front-end website and designed the visual part of our pitch.  I was so hyped up for the pitch that evening that I found myself pacing around the room and with zero appetite.  But rather than feel nervous, I felt more like I was in a zone, where the business really could provide incredible value to clients, consumers, and investors alike.  I just needed to explain that to the judges.

The pitches began in the early evening, with prospective entrepreneurs condensing their weekend of incredible work into just 3 minutes.  All of the presenters enthusiastically showed off their products, and did it with an essence of fun; there were no overly awkward moments or failed efforts, only head-nods, applause, and laughs.  (Check out all of the businesses here)

We were slotted as the twelfth and final presentation of the evening.  I delivered the pitch and fielded the questions, and I was quite happy with the performance: the website looked great (rather than PowerPoint, we had set up the visuals on our site to display during the pitch) and the judges easily understood the concept and the value to each party.

When the judge's scores rolled in, we found out that we were not going to win Startup Weekend.  Our score was in the middle, which I think was a testament to the great work that teams put together over the intense weekend.  I hope and believe that several of those teams will continue to work on their businesses, and maybe some will ultimately be successful (each Startup Weekend tends to produce at least one or two living businesses).  But the four of us at Txtern decided to chalk this up as a wonderful learning experience, and head back to our jobs and educations.

ANZ: Ideally Suited for Prototypes

Last month I spent two weeks on the other side of the world - one in New Zealand (Auckland) and the other in Australia (Sydney).  The purpose of the trip was a class: KIP (Kelley International Perspectives), which has the mission of teaching students about perspectives on business in other parts of the world.  Of course we had time to explore and be tourists, but we spent a fair amount of time visiting firms (10 in all) in addition to once-a-week sessions on campus back in January and February.

The main take-away for me from the experience stems from these countries' unique situations: They are both very geographically isolated - from every other nation, but especially from developed ones - and they both have very small populations (there are roughly 22 million Aussies and 4 million Kiwis).  They are also somewhat wealthy, developed, and American-like, stemming from their British origins.  In fact, Australia is often considered to be more like the US than the UK, and my own experience of Sydney was very much like visiting an American city, only the people had different accents.

All of these traits make Australia and New Zealand (ANZ) a perfect proving ground for new products destined for the US.  This is especially true for companies with established brands that they do not want to risk damaging for the sake of a new product.  And as it happens, many American companies are already leveraging ANZ in this way: We visited Kimberly-Clark in Sydney, who uses Australia quite often as a test market for its Huggies and Kotex brands.  They find that Australians react very similarly to Americans when it comes to marketing and products, so the level of success of a new campaign or new product there is a strong predictor for the same in the US.

This strategy may also work for a startup, but of course this strategy comes with the trade-off of needing to wait at least several months to get feedback from the ANZ market.  Also, I haven't dug much into the subject for the tech industry, but it would be great to see the results of companies opting to launch tech products in ANZ before the US and finding whether or not there was a correlation with success in the US.

Analysis of the Droid Landing Campaign

Note: For a marketing class project, we were to analyze a marketing campaign that involved social media.  Two classmates and I teamed up to produce the following.

Analysis of the Droid Landing Campaign

Ayushman Dutta, Jason Fletchall, Nirmalya Ray

Background

In November 2009, Motorola and Verizon Wireless entered the US smartphone arena in a big way by launching the Droid, the first phone carrying Google’s highly-acclaimed Éclair version of its Android operating system.  Arguably more notable than the phone itself was Motorola’s and Verizon’s marketing campaign, personifying the phone as a type of super-intelligent machine hooked into the “ever-expanding Android Market.”  The campaign spoke strongly to its target demographic (males aged roughly 18-30), as it fit in well with the enormously popular sci-fi thriller category of entertainment.  The campaign was widely considered to be a success, with sales of the Droid phone quickly eclipsing those of any previous Android phone.

Late the following Spring, rumors and leaks starting pointing to a new phone in the Droid line due out sometime in the Summer.

Enter the Droid Landing Campaign

On June 21, 2010, tech blogs lit up with the news that the YouTube account VerizonWireless had uploaded a short video featuring a human eye transforming into a Droid eye.  The video finished by naming its subject, Droid X, and a date, “07.2010.”

Within minutes, viewers had analyzed the video frame-by-frame and caught a mirror-image of text in a reflection in the eye, “@DroidLanding.”  A short journey over to Twitter revealed an account named “DroidLanding,” which had recently been opened and had tweeted, “REPORT: Droid X units have escaped! Get the stats on them at http://www.droiddoes.com . Forewarned is forearmed.”  Clicking on the link sent users to a Flash website featuring the phone with specifications listed and a “Coming Soon” note.

The DroidLanding account continued to tweet with increasing frequency over the following days.  The theme of the tweets was consistently one of a security organization warning citizens of a group of escaped Droid Xs spreading throughout the US, while at the same time injecting information about phone specifications.  The tweets often identified specific machines, such as “Droid X designate #3,” and began to give information about specific locations of the Droids, such as “Droid X designate #1 has been sighted in Nevada. Witnesses call it the greatest source of power next to the Hoover Dam.”

This led to speculation that Motorola and Verizon were organizing a scavenger hunt for Droid X phones.  And indeed, after two weeks of speculative discussion across tech blogs and forums, this was confirmed when on July 7 the droiddoes.com website posted official rules for a hunt.  The rules specified that the DroidLanding handle would sporadically tweet GPS coordinates over the next two weeks.  Each set of GPS coordinates would identify a location where a Droid X “designate” had landed, and where one determined and witty hunter could collect a free phone.

Sure enough, on July 8 DroidLanding tweeted coordinates that specified a location in New York City.  Within 30 minutes, the handle tweeted that the phone had been found, and later followed-up with a link to a picture of the successful Droid hunter.  This same pattern continued with 20 other phones being given away over the following 12 days in cities across the country.

Towards the end of the campaign, on July 15, the Droid X was officially launched, quickly sold out, and continued to sell out with each stock replenishment for months.

The Campaign’s Information Pathway

The campaign involved a fairly complex set of steps for consumers to follow, though the tech community as a whole helped individuals take shortcuts.  This figure shows the actual information pathway experienced by consumers.

The first step in the pathway was the discovery of the “Droid eye” video on YouTube.  A relatively small number of consumers needed to find it, as the path to the next step (1 on the diagram) was to post the video on tech-themed blogs and discussion forums.  Once in the blogosphere, the video received quite a bit of attention.  The path to the next step (2) was to analyze the video frame-by-frame to find the reflection in the eye.  Again, this could be done by a small number of consumers, since the path to the next step (3) was to simply post the reflection on blogs and forums.

The path to the next step (4) was intended for all consumers to take – it was the discovery and followership of the @DroidLanding Twitter handle.  At this point we believe the intended pathway and the actual pathway differ: The intended next path (5) was to find droiddoes.com via DroidLanding’s tweet to see images and specifications of the phone, but many consumers skipped that step and simply tried to decipher DroidLanding’s tweets for the locations of phones, then proceeded directly to discussion of the tweets on blogs and forums (6).  Likewise, some consumers checked out droiddoes.com but didn’t bother with the scavenger hunt.  In other words:

            Intended: All consumers 5 – 5.5 – 6

            Actual: Some consumers 5 – 6 and some consumers 5 – 5.5 – 6

Discussion of the phone and its associated scavenger hunt on blogs and forums (6) led to consideration of purchase by the consumers engaged in the campaign and also by those otherwise following tech blogs and forums.  Ultimately, the aspiration of the campaign was to have consumers go to a Verizon store (either in-person or online) (7) to purchase the phone on or near launch day, July 15.

Involved Technographics

The campaign necessitated involvement from almost all of the technographics:

• Creators: Found the messages in the eye and posted them.  Also the owners of the blogs who reported developments in the campaign.
• Critics: Main drivers of the discussions to find the answers to the clues in DroidLanding’s tweets.  Also drove the discussions of the specs of the phone itself (one forum alone reports over 250,000 posts)
• Collectors: Shared links to blog articles, droiddoes.com, and @DroidLanding with friends on Facebook and Twitter, thereby increasing awareness of the campaign.
• Joiners: Large chunk of the followers of @DroidLanding.
• Spectators: Large chunk of the readers of the tech blogs.

The Success of the Campaign

The main goal of this campaign was to generate buzz about the product, the Droid X phone, amongst the tech-loving community.  While the ultimate goal was of course increased sales of the phone, we believe that the intention was to generate buzz amongst this relatively small but influential community, which would then recommend the phone to friends and family members outside of the community.  And this was anecdotally true at least: One of us purchased the phone on launch day and subsequently had three decidedly non-tech-community-member relatives purchase the phone within two months.  In terms of hard numbers describing the buzz surrounding the product:

• The number of people who viewed the “Droid eye” video on YouTube was more than half a million. Combined with views of other commercials for Droid X on YouTube, the number was more than a million.
• The @DroidLanding Twitter handle gathered more than 30,000 followers.
• The forum droidxforums.com counted more than 250,000 posts.
• Other success metrics on this dimension would include “mentions” on Twitter, “shares” on Facebook, posts on tech blogs, and comments on tech blogs, though those measures were not readily available to us.

A sub-goal of the campaign was to create awareness of the technical specs of the phone to help move consumers to the consideration step.  On this dimension, the campaign did fairly well, as measured by traffic to droiddoes.com:  The Internet traffic rank of the website went from more than 100,000 to 5,000 in a single day and stayed in the high 20,000s for months in a tech industry where technology quickly goes obsolete.  At its height, this accounted for 0.04% of the total traffic on the Internet (see Traffic Stats here).

In terms of speaking to the targeted demographic, the campaign also did well: The audience for droiddoes.com was skewed towards males aged 18-24 with college educations (see Audience here).

The ultimate goal of the campaign, increasing sales of the device, could be measured in part by sales data.  While this information is not accessible to us, we can guess that sales were excellent as the phone was consistently sold out for months (as noted earlier).  However, it would be difficult to attribute sales numbers directly to this campaign because there was no built-in mechanism for tracking sales through it.  How would Verizon know that what caused a person to walk into their store and buy a Droid X was that they followed @DroidLanding, or that they read about it on tech blogs?  The great sales numbers could have been caused by the rash of Droid X TV advertisements playing at the same time as this campaign.

Recommendations for Campaign Designers

With the intended information pathway leading from followership of @DroidLanding and subsequent viewership of droiddoes.com not actually playing out for many consumers, we considered recommendations for increasing the promotion of the Droid X device’s technical specifications.  While @DroidLanding did tweet tech specs regularly, we found these tweets to have rung false with the main theme of the Twitter handle as an organization warning citizens of escaped machines.  For example, “Droid X shoots in 720p. Which means you can really see the look on your face when you find one” does not convey the same sense of urgency or danger as the other tweets.  Alternatively, @DroidLanding could have tweeted links to videos describing the specs of the device, along with text conveying the videos as “reconnaissance” or “briefing” information.

We also considered other ways of reaching the target demographic of the campaign (males aged 18-30).  The campaign spoke very well to those in the demographic who enjoy sci-fi thriller movies and games and are also tech fanatics, but they comprise only a part of the demographic.  Many of the ads that accompanied the campaign (like this one) attempted to bridge that gap by showing office workers interacting with the phone, but they did not resonate with the younger end of the demographic, whose members are in high school and college.  Instead, the supplemental ads could have included college-age men and featured the phone’s tight integration with Facebook, or the customizability of its live wallpapers.  This could have turned this younger side of the demographic into trend-setters for the Droid X.

Velocity Conference: Day 3

The third and final day of the conference had the two dozen of us back in the comfort of the Faculty Club in Berkeley.  The assembled cast included several veterans and a relative newcomer:

• Gary Rogers, former CEO of Dreyer's Ice Cream
• Louis Jordan, SVP of Corporate Finance at Starbucks
• Joe Walsmith, Entrepreneur in a number of companies
• Rick Roethke, Founder & CEO of Barrington Management Co, a real estate firm
• Nicholas Seet, Founder of Auditude

Gary Rogers told us a fascinating tale about visiting an ice cream shop penniless, jobless, and looking for whatever work they had.  Two days later, he was the new owner of Dreyer's Ice Cream.  His ability to seize opportunities whether or not he seems to have the resources to do so absolutely exemplified the entrepreneurial spirit, and it served him well throughout his career.  He gave us seven points of advice to take with us in our own careers:

1. Make the most of every day (and he extended this to include "be serendipitous")
2. The joy of life is in the struggle
3. Be a builder (the process is the most fun part)
4. Prepare to be lucky ("fortune favors only the prepared mind")
5. Be a persistent optimist ("there is no such thing as can't, only won't")
6. You can only make some of the people happy some of the time, and that's enough
7. Develop a sustainable competitive advantage and leverage it

Rick Roethke struck me as somewhat of a modern-day folk hero.  He actually joined us for many of the sessions during the conference, including the cocktail reception at Plug and Play, where I talked with him for quite a while.  "I'm not like all these people here," was one of the first things he said to me.  When I asked what he meant, he explained, "They probably wouldn't like the way I do things."  He continued to describe his career: laid back, enjoying the ride for what it is, never working too hard, taking vacations when he wanted to take vacations (even if it meant ending jobs), a lot of luck, finding deals by talking with people on vacation, and so on.  For Rick, his storied career wasn't for some feeling of achievement, purpose, or altruism; it was something to do that provided him the means to enjoy life.  His main concerns were world travel and relaxing in San Diego.

With all that we hear in our professional lives, and especially in business school, about success and taking on more projects to get ahead, Rick's story causes a bit of pause.  Yes, there is another way.

Velocity Conference: Day 2

A few weeks have gone by since the conference wrapped up in Berkeley - I spent two with a class in New Zealand and Australia (perhaps more on that later) and one back in Bloomington getting re-acclimated to the usual school life.  But I'd still like to share some of the insights I gained from the wonderful Velocity experience.

Day 2 had us traveling the Bay Area to meet with several organizations living the Silicon Valley lifestyle.  First up was Google, a place I've visited many times but which always has something new to offer.  Part of the "new" this time was a rude tour guide, a software engineer who had obvious disdain for us business students - my favorite quote was "People will a lot of times write code up here on the board... but you guys wouldn't know anything about that."  (I suppose his attitude gives validation to my earlier thoughts on MBAs.)  But some good insights into Google's innovation-related incentive system came out as well: One important piece is the practice of holding people accountable for goals beyond their control.  Suppose you're in a cost center, like development support, but your bonus hinges on a profit center's, like Android's, revenue.  What are you going to spend your spare time on?  Another piece, of which the managers we talked with were particularly proud, was that employee performance is measured by impact, not effort.  In other words, evaluation is based on how many people you get excited about something, not how hard you work.  Does that encourage entrepreneurial activity?  I'm not convinced on that point, but it certainly encourages a focus of existing entrepreneurial activity on things that matter to lots of people.

Our next stop was Sonicwall, a B2B company that provides top-notch firewall hardware, software, and services to (primarily) small businesses.  We met with members of their executive team to hear about working in a high-growth environment.  The key, one of the executives told us, to entering a new market is to not look at what competitors are doing, but to instead imagine you have nothing to do with the market and simply solve the customer's problem.  His favorite line of thinking was to imagine how LL Bean would enter the aviation market.  I remember hearing something very similar from Aaron Patzer, founder of Mint.com, when he spoke to all Intuit employees shortly after the acquisition of Mint by Intuit.  When speaking about the beginnings of the company, Patzer focused on the fact that he completely ignored what Quicken was offering and simply thought through what the average person wanted to see about their finances.

We finished off the day at Plug and Play Tech Center in Sunnyvale, the world's largest business incubator. The tour took us through mazes of cube farms grouped into themes by nationality, alma mater, and sometimes subject matter (like "mobile app development").  The unique decor found in each nook and cranny of the place made me feel that this was a truly creative space fit for entrepreneurs.  When our host explained how Plug and Play works, I was surprised to hear that it does not see itself as an incubator - it's a real estate firm.  It offers rental office space to entrepreneurs, and the relationship can end at that.  Of course, it also invests in some of its patrons (about 1/5 of them) and provides services like mentoring and introductions to VCs, but all of that is a la carte.  After the tour we heard from a panel of entrepreneurs housed in Plug and Play itself, who gave us advice on starting and running a business in the Valley.  One valuable nugget that came out from the panel was the belief that when you're starting a business, you have to look at your community as if you're on a playground: everybody might as well be your friend, regardless of experience, age, title, and so on.  Another nugget: If you're relying on secondary research to start a business, you might as well build nothing and just give up.  You must conduct primary research to really understand a new market.

The end of the day brought us a cocktail reception in a Plug and Play cafeteria with dozens of Kelley School of Business alumni in the Valley, and headlined by Art Norins, founder and CEO of Nor1, Plug and Play's largest client at something like 120 employees.  Back in October, Art spoke to us in Bloomington about the founding of his company and about networking in the Valley, so it was a bit of a reunion for us.  This time he addressed the challenges with rapid growth, as Nor1 has expanded from just 70 employees when we saw him five months ago.

Armed with piles of SWAG from the day (I was particularly fond of my Android keychain flashlight), we boarded the bus for the trek back to Berkeley, where we would close out the conference the next day.

Velocity Conference: Day 1

This morning kicked off the latest instance of a dozen-year-strong tradition for Entrepreneurial Management Academy students at the Kelley School:  We traveled to the Bay Area to learn about, at ground zero, the most vibrant startup culture in the world.  The Velocity Conference is put on each year to expose entrepreneurially-minded IU MBA students to the culture, the industries, and the financing environment of Silicon Valley.  Why this particular place?  As the mastermind of the Velocity Conference pointed out in his kick-off talk, the last 30 years in the Valley has seen more value creation than in any other place in any other time period in the history of mankind.

That mastermind was Dr. Jack Gill, founder of Vanguard Ventures, former faculty at Harvard, and IU alum.  He gave us a talk on his research into understanding the relationships between intelligence, leadership, and entrepreneurship.  As he posited, "intelligence" as we normally understand it is concerned only with the left hemisphere of the brain (logic, analytics, verbal skills), and thus our education focuses almost exclusively on developing left-brain skills.  However, an analysis of all Fortune 500 CEO's revealed that, in general, they do not possess superior left-brain skills, but rather they possess superior interpersonal and intrapersonal skills associated with the right hemisphere of the brain.  In other words, they are confident in themselves and they have the ability to build positive lasting relationships, and they are merely "good enough" at the core business subjects we learn in school.

We also heard from Andrew Smith, Founder and CEO of Advanced Transit Dynamics, a company that produces the Trailer Tail, a contraption that mounts onto a tracker trailer to reduce drag and therefore improve fuel economy by 5-6%.  Starting from his idea getting launched by winning the Rice business plan competition in 2006, he took us through his journey coming out of business school as an entrepreneur, and offered nuggets of advice that he has picked up along the way.  He uttered numerous quotable lines, including, "Entrepreneurship is mobilizing resources that you can't control."  How true: The art of entrepreneurship (in both a startup environment and a corporate environment) lies in inspiring people to help you achieve your goals with the least capital possible.  Need a prototype built?  Find some mechanical engineering students at a local university and see if they want to build one for a class project.  Getting a lot of money early can turn out to be a burden if you lose sight of such valuable frugality.

Other speakers included Greg Oslan, President and COO of Narus (now part of Boeing), and Rick Johnson, CEO of Johnson Ventures.  Greg took us through his experience successfully crafting turnaround situations, while Rick gave us his perspective on what makes a good business.  Our final speakers of the day, Sanjay Subhedar (founder of Storm Ventures and IU alum) and Tim Walsh (VP at Silicon Valley Bank and IU alum), shared with us their thoughts on financing in the Valley.  They lamented that it is becoming increasingly difficult to find good deals out there, not because there is a lack of ideas, but because there is a lack of need for funding; hardly anyone needs to build a manufacturing facility or even a storefront anymore so venture capital is limited to later-stage, high-growth period companies.  What I found particularly intriguing about their talk was their nonchalant acceptance of the beginning of a new tech bubble, something with which I'm concerned.  Sanjay half-joked that he was really looking forward to the bubble, because his companies would stand to be acquired for top dollar by big players like Google and Facebook.

Tomorrow we're on the road, visiting Google (to learn about corporate innovation), SonicWall (to learn about the rapid growth stage), and Plug and Play Tech Center (to learn about the world's largest incubator).

An application of Outcome Driven Innovation

The unique 7-week class schedule of the Kelley School of Business has meant that this week has been chalk full of final exams, projects, and presentations.  From among that intensity has emerged a project applying a particularly helpful tool for corporate innovation: Outcome Driven Innovation (ODI).  ODI has its roots in the "jobs" methodology I wrote about a few months ago, as it involves identifying outcomes that customers are trying to achieve with a particular product type.  The tool specifies five steps in the research process:

1. Plan outcome-based interviews
2. Capture desired outcomes
3. Organize the outcomes
4. Rate outcomes for importance and satisfaction
5. Use the outcomes to jump-start innovation

For the subject of our research, the four of us team members selected Oncourse, an intranet tool used within Indiana University for the purposes of facilitating classroom document sharing, calendaring, and communication, among other uses.  We found the ODI methodology to be especially helpful in breaking through the feature requests for and complaints about Oncourse that were flung at us as we interviewed users, allowing us to see the truly greatest areas of opportunity for innovation of the product.  Our summary memo is below.

----------

Executive Summary

After conducting primary research and applying the opportunity algorithm of the Outcome Driven Innovation (ODI) model, we concluded that the outcome with the most opportunity for improvement is one that maximizes student preparation level for class.

Background

Oncourse was selected for several reasons - it is a well-known product among students at Indiana University, playing a central role in the students’ academic experience.  However, since each student uses Oncourse in a unique way, we thought there was opportunity for innovation since a commonly agreed-upon usage method does not exist.  We explored various outcomes students are trying to accomplish using Oncourse, helping us understand specific stress points with the product and also innovations that would enhance the product in the most meaningful ways.

Application of the Outcome Driven Innovation Methodology

The ODI methodology identifies a qualitative as well as quantitative way of fine-tuning outcomes that customers are trying to accomplish, solving one of the problems with qualitative research: customers can rarely tell you what they want. For instance, when asked about a time of frustration using Oncourse, one student responded “professors upload files in different ways, there is no standard method.”  While this comment referred to a feature, specifically file structure, we had to probe him for a deeper understanding behind his response.  Therefore, we asked him what feelings he wanted to experience or avoid using Oncourse, to which he responded, “I don’t want to become impatient.  I want to feel calm and the process should not require too much of a thought process.”  By understanding the emotional context of the high level feature comments and suggestions, we were able to analyze and aggregate the student experience with Oncourse.  To replicate a representative sample population, we selected males, females, Kelley students, non-Kelley students, domestic students, and international students.

Upon analysis of all the responses, we discovered six distinct outcomes that students were trying to achieve with the product. These outcomes addressed specific issues with the product that are important to students, including preparation for exams, access to supplementary course material, and making up for a missed class. Next, we followed up with the respondents by having them rate the outcomes on importance and the level to which they were currently satisfied by the product. We then utilized the opportunity algorithm to identify the areas of greatest opportunity, finding that the three greatest opportunity areas were maximization of preparation for class, minimization of stress related to exams and assignments, and minimization of time necessary to see everything related to the school experience. Finally, we brainstormed possible directions for innovation based on the outcomes with the greatest opportunities.

Conclusions

We learned that Oncourse has several benefits but also several areas of improvement. The respondents use Oncourse to satisfy the basic jobs that the software was designed to perform: obtain the material needed for classes, exams, homework, and even updates on social events.  However, emotions behind the responses indicated that Oncourse could perform these jobs either in more efficient, innovative, or personable methods. 

The opportunity matrix revealed that maximization of students’ preparation level for class is the outcome with the widest gap in the current version of the product. In order to address this, we identified ways to better organize class information to make it easier to consume and more relevant for the student. Sample ideas include: a uniform interface across classes, a list of required vs. recommended actions for class preparation, and outlook calendar sync with class schedules and deliverable dates.

At the same time, we identified challenges with the ODI data gathering process: it is difficult to steer interviewees away from merely suggesting features or logging complaints, and equally difficult to draw out clearly distinct outcomes.