October 22, 2010 § 4 Comments
I was rather inspired by this VentureBeat article in which Mark Zuckerberg claims that profit isn’t a big deal for Facebook. This seems like blasphemy in light of the oh-god-we-aren’t-profitable bust of the late 90’s, but I’m noticing a trend: many startup websites taking what they call “the slow, cautious road” to profit.
For example, I recently interviewed with Yelp for an ad-delivery PM position, and I talked with them at length about the major monetization opportunities I thought they were missing. Yelp has a few problems. The ad inventory is tiny. They have ad placement issues. Worst of all, their mobile ad story is to channel users back to the mobile version of the website from the app whenever possible. Taking users from an app to a webpage is a terrible user experience, and they are literally leaving money on the table by keeping ads out of the app. After questioning the business director in detail, I got the same line Zuckerberg is throwing out: there’s plenty of time to make profit later.
It would be easy to under-think the ad experience and annoy users with Flash banner ads, or misplaced text ads. So I can understand cautiousness insofar as it means getting the ad targeting and delivery user experience right. But these days, like it or not, ads pay for the content of the internet, and barring massive innovation in the micropayment space it will for the foreseeable future. Eventually every site needs to solve the advertising problem.
While we’ve all seen ads done wrong, if done right, they can actually be useful to a user. For example – if I am a mobile user searching for sushi in my area, it would be trivial for Yelp to serve up a coupon for a sushi bar down the street. The more targeted ads get, the more users are likely to engage with them, and the more everyone profits. And if the ads are placed correctly, users can just tune them out if they aren’t interested.
So the perfect model of internet monetization is yet to be found, but there is plenty of opportunity for innovation in the ad-delivery space, and the first dot-com to get there could have the next Google adWords on their hands. I’d argue that this potential is what keeps Facebook’s valuation so high despite their lack of profit.
October 15, 2010 § 1 Comment
I work for a Microsoft applied research lab (Live Labs Pivot), that was dissolved into Bing just last week. Pivot is a cool piece of software, but it never made the ambitious impact I expected. So I sat down and thought about what went wrong. I talked with my management. I talked with our out-going technical fellow. I realized that I’d known the answer all along.
Applied research organizations like Bell Labs, Xerox PARC, Google Labs, were created to meld research and development. Great research happens in a number of universities, great development happens in a few companies. But true R&D is a rarity. An obscene number of important inventions (networked computers, wireless networks, C, UNIX, the mouse, the GUI, lasers, etc. etc.) come from labs – so why don’t they accrue value to their parent company? Why don’t I work for Xerox instead of Microsoft?
Simply creating value for humanity isn’t in most companies’ DNA – they are interested in R&D insofar as it impacts the bottom line. Despite the laundry list of patents, labs rarely make an impact on the business. So are labs just rogue organizations filled with wannabe academics interested in tinkering? Or are the parent companies so blind, that they can’t possibly see the impact of the lab’s innovations?
Certainly, some organizational dysfunction is to blame. As organizations become entrenched in the market, they become conservative and inbred. I guarantee most of Microsoft’s executive management only got a handle on this whole social networking thing after the Facebook movie. And Microsoft execs aren’t alone. Any Fortune 500 executive will be just as short sighted and out of touch. It was the Xerox executives, after all, that let Steve Jobs come in and take a look around.
But, despite the constraints of an out-of-touch organization, I believe Labs could (and should) make an impact. Labs are purposefully rogue organizations that cultivate a culture of disruptive innovation. Labs experiment, and while not all experiments are successful (see Google Wave), some clearly incubate game-changing ideas. The challenge of a Lab is to hone the mission, release early and often, and look for the opportunity to impact the business with every experiment. Most Labs fail at this, because the engineers that are attracted to Labs lack the business sense to create viable business opportunities for their innovations. Pivot fell into this trap.
Even the most conservative organization can’t survive without R&D. Execs that realize they are out of touch (like at Proctor and Gamble) hire design consulting firms to tackle hard problems and innovate new products. Microsoft prefers to acquire innovative companies than develop innovations in house. But there is a tax to outsourcing innovation. At P&G lack of in-house innovation is a self-fulfilling prophecy – they will always be dependent on the IDEOs of the world to create new products. Microsoft frequently acquires an interesting start-up only to let the product die, and alienate the start-up’s entrepreneurial talent.
R&D Labs seem like a viable way to successfully innovate in-house. But organizations need to provide an opportunity for Lab products to succeed. And Labs should be built on the premise of creating business value, and stocked with employees who have the savvy to make this happen.
October 8, 2010 § 2 Comments
There are a couple of basic approaches for solving design problems in the tech industry. When I started to write this post, it was about the failings of scenario-focused design (I was forced into a pointless scenario-focused design brainstorming session recently…). But, I realized that I needed a more balanced take – so here are my thoughts on common methods for approaching design problems:
Scenario Focused Design
At Microsoft, this is the party line. We have an entire division of people shaping “best practices” and they preach this as gospel. With this paradigm, a designer starts with an audience, represented by a single person. For example, I work on a small business application, so I’ll design for “Jane”, an interior decorator. To me, “Jane” represents all personal services companies with less than 5 employees. I spend time with Jane, understand her needs, watch her work. I learn about her pain points. I then design to address these pain points.
Who uses it: Office. Oh Office.
Pros: You are designing to solve real problems that actual people encounter. That is good.
Cons: It is noble to extract the user needs from the technology. However, with the decades-old Office code-base it is also pure fantasy. Office wastes months of design time starting from scratch, only to make iterative improvements to very mature products. I imagine end-users telling Word PMs about trouble sharing docs, but that will inevitably translate to “better integration with SharePoint”. Trust me, better integration with SharePoint doesn’t solve anyone’s problem.
My take: Understanding high-level user needs is important, but doesn’t necessarily lead to good, usable software.
Iteration and Data Driven Design
This is a design invention made popularized by internet apps. The goal: instrument everything. Everything you do on a website — how many links you click, how long you spend on each page, each step you take in a wizard is tracked and reported upon. Design decisions are made based upon the data collected from the website. Designers make changes based upon any identified problems or bottlenecks. Frequently, this strategy involves multivariate testing of different designs, until an ideal design is found.
Who uses it: Google, Zynga, pretty much any legitimate online business
Pros: Design decisions are based on data, not intuition. No speculation needed about the best design – statistics solve the arguments for you. I like using this paradigm gauge the interest for new features, as well. For example, if there is a discussion in the Zynga office about adding a feature to Farmville, they’ll put up a link saying “get this feature”, and track how many users click on it. If enough users click on it, they develop the feature. Engineers understand and like this approach.
Cons: You can take this too far. For example, Google multivariate tests different button border widths. Why? Also, if you have any great designers on your team, this approach isn’t the best way to take advantage of their talents. And you may alienate them. See Google. Also, while this paradigm can help make iterative improvements, it may not point out bigger issues. If you aren’t fundamentally solving a real user problem, who cares that they can get through your wizards?
My take: Asking what users want is unreliable. Tracking users, and making decisions based on what they do is ideal. If you have a product and a team is full of smart people (but no user experience visionaries), this is a fantastic design strategy. I believe some level of data-driven design is absolutely fundamental to modern design. But it isn’t a way to create innovative, visionary software.
I’m actually making this paradigm up, but plenty of people design with goals, especially at Microsoft. Goal-based design starts with a mission statement. Something like: I want to fundamentally change the way users interact with data, I want to increase my search engine market share, I want to enable people to view cute pictures of cats with silly captions. At Microsoft (the epicenter of platform technology), goals are frequently more useful than scenarios. The design isn’t addressing user pain points – it’s pushing the envelope.
Who uses it: Bing, Pivot
Pros: This paradigm is ambitious and allows you to develop software beyond what your users can imagine. Take Bing for example, they aren’t solving real user problems, they are completing with Google. Google as a search engine is completely usable, Bing’s only hope is to change user’s idea of what a search engine should do. This is why Bing markets themselves a “decision engine”. Remarkably, this single minded devotion to increasing market share has increased market share. I don’t think it’s created any great UX though.
Cons: It is easy to get off track, and make technology for the sake of making technology. It is too easy to lose sight of what the user wants and needs. A great example of this is Live Labs Pivot. As “data visualization technology” it is innovative and interesting, but it doesn’t have any grounding in user needs.
My take: Combine this with scenario-focused design, and data-driven design you might have a strategy. It doesn’t work on its own.
Not much explanation needed here. The team has a ruthless leader with a vision.
Who uses it: Apple
Pros: The only tech I’ve ever seen that is beautiful, usable, and useful falls into this category. A team of great designers can put together something beautiful. Anyone with access to a user research lab, or A/B testing can make something usable. Good PMs can make useful software. But that combination of all 3…. That is something.
Cons: Like all dictatorships, it only works when you have a fantastic dictator. You also need a team that communicates well with the leader, because the leader can’t possibly be involved enough in the minutia to recognize potential technical issues. I feel like this is where I should fake cough iPhone 4.
My take: Find yourself a benevolent dictator ASAP.