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.