-- Dr Linda Lewis (Columbia University College of Physicians & Surgeons)
Google has been working on their automatic car tech for ~5 years. Amazon has been working on the kindle line for ~7 years. Google's project glass took ~4 years and they've been working on social for ~3 years. SpaceX on the falcon for ~5 years and Tesla Motors on the roadster for ~7 years.
Sometimes the better thing to do is quite literally do nothing before you go pull off a Nokia like move (sucking up to the losing horse in mobile) or the like. That doesn't mean pull a RIMM either.
Google and Amazon also have a recent history of shipping things. If Yahoo were able to ship things on a routine basis, but then this big opportunity came along that required 18 months of development, maybe it would be worth a try. But if you already can't ship stuff, you don't want something that everybody thinks on day one will take 18 months, because it will certainly take longer than that.
Companies have to react to where and what they are. A perfectly sensible policy for one company may not work for another, and it's certainly no criticism of a given policy to point out it isn't universally applicable to all companies.
All of the products you list are hardware, which doesn't count. The only exception is Google's social stuff; Google had shipped many social products to get where they are today including Gmail, GTalk, Orkut and Buzz. They didn't sit in their offices and build Google Plus for 10 years, they iterated again and again, and that's what Mayer is asking for.
GMail took 3 years from prototype to launch. Google Search was also 3 years from prototype to incorporation. G+ was shorter, but was built on previously-existing infrastructure that's been around for a few years.
Now, it's better to spend those 3 years iterating than planning - rumor has it that the GMail prototype was built in a day. But it's worth being realistic about how long it takes to build a world-changing product - it's a long road. (In fairness to Marissa, I'm sure she knows this, and I suspect she's just trying to get the release cycle down so that Yahoo can make forward progress.)
There's a big difference between major projects and adding features too.
Maybe this is not the right time for Yahoo to do 3 year products simply because they suck at it (I spent more than 3 years at Yahoo, and I spent most of that time trying to shepherd projects through to the point my engineering team would actually get a go-ahead; we were a service function without direct control of a product, otherwise we should've just gone for it rather than wait...), and practising on 6 month projects could still bring a ton of useful improvements or smaller services. One thing to keep in mind with Yahoo is that it has a vast array of sites and services just sitting there - I bet there's a ton of poorly monetized services that could get drastic upgrades in well below 6 months if there's just sufficient fire behind someones asses...
Then they can start trying to add the standalone world-changing stuff again later, if they're successful.
Games/Music/Hardware/Software always iterate to completion - the web isn't special in terms of this. The key component is and will remain time to search through a product space to where you can actually add value.
What pbiggar is saying is that hardware doesn't make sense to measure on the same timescale as software, not that it doesn't involve iteration. Think about the "time to ship" of sites like Facebook, Twitter, Youtube, etc and you start to see numbers closer to or within the 6 month time range.
FB, Twitter, and YT were incredibly small teams of less than a handful who knew exactly what they wanted to build. Expectations were minimal or non-existent when they launched. They didn't have a corporate board, a CEO, or Wall Street looking over their shoulders for monetization.
Looking from the outside, they seem to have a dysfunctional culture around shipping software with all the additional layers of management. Hopefully this changes and they have a chance producing meaningful products but I'm not hopeful.
This I think is a good rule for Yahoo! You need to have a real product in the market to get users. Pre announcements don't drive engagement, usage, revenue, or advertising sales. Eyeballs do. Users do.
Also, the it needs to be a product that could reach 100 million users or $100 million dollars is a great filter. It provides focus.
Unfortunately, based on the last 10 years of Yahoo's corporate history, there are probably a lot of bad habits and corporate culture shenanigans that will need to be dealt with before Yahoo's actions match their CEO's marching orders.
At least Yahoo is trying to do something hopefully more interesting than being another internet media company held over from the AOL era of the internet. Perhaps soon someone at Yahoo! will be able to clearly explain what Yahoo! is and does.
I don't see the point of this rule. It seems like it would instill fear, and cause hesitation and second guessing. But I don't like rules in general, I prefer having philosophies. Personally, I would encourage failure and risk taking with limited downside and unlimited upside.
There seems to be much adoration on HN for anything Marissa Mayer says. I watched a few interviews of her, she has an uncomfortable personality, hard to listen to imo.
> Personally, I would encourage failure and risk taking with limited downside and unlimited upside.
But isn't that sort of what she's doing? She is limiting the downside by setting a time limit. She is ensuring people aim high enough with the $100m number.
I worked in engineering in Yahoo 2003-2005 (I feel old - it doesn't feel like 7 years ago...), specifically the European biling platform (yes, Yahoo had multiple - on the order of 10 distinct billing systems at the time, for various reasons, some good some not so good).
I spent those years without writing a single line of code at work, despite a small team, because about 2/3's of my time was taken up reading product requirements documents from business units that wanted to add features tied in with premium services / billing and attending project meetings.
Of all those projects, maybe 10% went anywhere. The rest spent months in PRD hell. Whole business units where dithering back and forth as to whether they should even try selling stuff, when the resource cost of trying was substantially smaller than the resource cost of the endless project meetings.
There were probably no $100m opportunities amongst the ones I reviewed when limited to the countries in Europe that actually were actively involved with the billing team. But that was part of the problem: People were far more concerned with delivering stuff that was successful than with the big picture, and so we only got go-ahead for projects when the business unit were really, really sure they'd make a good amount of money from adding premium services to a product.
And then only market by market, with many markets remaining totally unserved because the local team didn't believe in the project enough to want to stick their necks out. While I was there, we kept trying to get Yahoo Italy and Spain to start billing for something - anything - for example; in 4 years that went nowhere.
Downside: like you say, it'll cause second guessing. It might be a genuinely great idea but no one is sure how it's going to spin out in the real world, which could create a business of conservative ideas.
Upside: Yahoo needs new things to get the attention back to "Yahoo has released a new product, and it does X" rather than "Yahoo hasn't done anything and we think they're sucky".
It depends if the 100 million users is a fast and firm thing, if it's a case of get it done in 6 months or aim for 100 million users it could be more interesting. Lots of crazy idea being done quickly.
To me it would inspire ambition, not fear, but I guess it depends on the listener.
If you work at Yahoo (or Google, or Facebook), and the product you want to work on ins't going to affect 100 million users, then you should probably be working somewhere else, it's simply the nature of their businesses.
It's not meant to be easy, and it never will be, but it has to be the goal.
If you want to make niche software, Yahoo is not the place to go it, anymore than Unilever is the place for people who want to make small amounts of high qualty hand made soaps.
I just got done participating in Startup Weekend. I was scared, but I worked harder and faster than maybe ever. In the end it paid off. We had a MVP to show off and a somewhat shaky business plan. But the fear and the speed help.
This pretty much changed my view of her--it displays a lot of naiveté about how long it takes to develop software. I guess it depends on the market, but I'd be extremely skeptical about shipping any world-shaking software 6 months from beginning to write it. Assuming you allow at least a month for testing and debugging--which is EXTREMELY aggressive--that leaves just five months for planning and execution. For any kind of complex software you're looking at at least two or three weeks for planning, at a large company like Yahoo even a month seems very aggressive. So that leaves 4 months for development. You're going to lose at least a week to two weeks to meetings related to issues, work distribution, and so on. Assuming they're using Agile (if not, you have to allow for project planning meetings etc), and give them 1 month sprints to be generous, you're looking at about 3-4 iterations of the software before you ship.
I just don't think this is realistic. It's a nice goal and a nice thought but unless they're building HTML 5 games or something and counting those as products it's just not realistic. But we shall see.
I'm guessing you are very much her target audience, above are a bunch of traditional ideas about development that result in huge, drawn out processes for out of date designs that more often than not have some big omission missed during planning. In the meantime you've got a team so ingrained in how their project should work (after years of effort, probably forgotten what they're even building, lost in a world of type masturbation and implementing whatever cool tech they read about today, and demotivated because they've delivered F.A. in the meantime), regardless of its function, that pivoting the mess post-delivery is now impossible.
Yahoo isn't exactly sending men to Mars, they're cobbling together fairly simplistic web apps to serve ads and perhaps even subscriptions that at best need a bit of fancy realtime communication or maybe a very large database in the background. For these kinds of apps and open source where it is now, you can get 'prototype one' built in about 90 minutes by one guy defining a bunch of models and a 0 byte index.html.
Given a team of 3, one week is more than enough time to have a couple of buttons, some rough page layout, and most importantly an increasingly sterling idea of the problems you're going to start running into and how you need to adjust. It's called iterative software development, it's great.
Now just add one PM to whip the software kids in the right direction, and you have a viable chance at delivering an internal demo in 2-3 months.
Ok, yes. If you're developing a single-page Web app--or even a handful of pages--then you are correct, 6 months is an eternity. For an entire project though, which I understood was the thrust of this article, it is an extremely short period of time.
If Yahoo's goal is to develop simplistic Web software then I retract my statement, but we're talking about something absolutely worlds away from the type of stuff that Google has been producing, or even Yahoo over the past several years.
I'm not sure, but I don't think the implication was that the project must be 100% perfect in 6 months, just shipped. Slap a BETA tag on it, and it's still shipped, just not polished.
Which product at Google took six months or less to develop from scratch?
This is not to say that a six month development cycle is impossible. There just has to be an understanding that there will be a trade-off in quality. Maybe Mayer is in the "get something out there fast, and reiterate based on feedback" boat (which would make me respect her more) but going from 0 to 100 in six months is impossible with the scale of projects Yahoo! works on.
Assuming naivety is neglecting multiple data points, among them her extensive experience at Google working on or with some of their most successful projects.
Why start there? Why not look at the whole picture and loan her the benefit of the doubt, saying, "I believe with your experience it's likely that you're familiar with software development. Therefore I won't assume this is a massive brainfart, even if part of my mental model of the world thinks it could be. Without that assumption, what are you trying to communicate with this, and why? What can I learn from this, and do I need to update my mental model?"
Assuming naivety is unreasonably dismissive, and says more about the critic than the policy or policymaker.
I'm surprised by the negative comments here. The idea of shipping a minimum viable product should resonate well with startup-minded folks. I believe PG himself once said if your project will take longer than 3 months to ship, it's too long.
6 months is a good target. It'll keep new projects lean and focused. It should sway the balance of power more to engineering while forcing the business-side / product management to work tightly with engineering... Or force the product managers to take a back seat for the initial release of a project.
It's not the idea of shipping in six months, it's the idea of shipping something (in six months0 that will be adopted by millions of users.
We don't have the full context of her statement, and I'm guessing (hoping) that she isn't expecting version 1 to be a runaway success, but will allow the team to continue iterating and pivoting, if necessary, before making the determination of whether the project was worthwhile.
I didn't read the quote that way and don't think it's unreasonable to launch an MVP in six months. The other two criteria are business cases against starting and are used to decide which projects should proceed towards their MVPs.
When Google launches a beta (or even alpha), they watch for adoption and "hockey stick" growth. If a project gains traction, the MVP will be augmented with features during the 2-3 years it takes to reach 100M users or $100M.
I agree. My rule of thumb is that you need to shrink a project down into 3 month deliverables. If you aren't going to deliver something that stands alone and is useful in 3 months, then don't bother as the world will likely change before you finish. I realize that some big projects and products take much longer than 3 months start-to-finish but there should always be 100% useful milestones every 3 months.
A startup spending their first three years without shipping a product ("shipping") would be more of a problem than something with Yahoo's stability making something over several years. The risk is much, much lower.
I'm sure it does, but if I'm working on a new developer product how do I make the case that it's the next YUI? I think these sort of line-in-the-sand rules lead to people erring on the side of not doing anything.
Those sorts of estimates are easy. You just go "total market size" * "my potential penetration as a percent". Yahoo would have the numbers available for the former, and you guess the latter.
Point is, time to deliver will matter... And stop doing the inconsequential many... How can anyone argue against that? Wonder when the first big reorg/cut happens, that will be when you get a true sense of where they are going.
"You ate the food! no one made you eat the food! but you did, so now where's our $100 million dollars?"
Really if you want big $100 million dollar wins you had better make with big million dollar rewards for the people delivering. That is impossible because the management bureaucracy will soak that right up. Yahoo should focus on rewarding the right people through acquisitions and investments.
I keep looking at this comment and wondering who "the right people" are. Do you mean buying outside talent, by aqui-hiring? Or dumping a million dollars on random developers within the company?
I suggested acquisitions and investment in outside companies that are on track to create a $100 million product within six months but are maybe undervalued by the market. They need to look for situations where there aren't six layers of management to soak up all the rewards.
I've never heard of a company dumping millions of dollars on random developers and I don't think that's possible. They may dump millions of dollars on a VP, but by the time it "trickles down" through all the layers to the team it comes out as "you're lucky to have a job." So in almost all instances it's telling people to kill themselves to launch a $100 million dollar product in six months just so they can keep their jobs (with free food of course). Those people are going to take option 2, quit and go somewhere else, and the product will never launch.
The goal of $100 million isn't that Yahoo wants money. They want to be a sexy, ambitious, developer-oriented employer like Google. They want to experiment, and break things, and most importantly identify what is and isn't working. Rather than letting some cut-rate dev produce a middling Japanese Finance page for his whole career, they want a few impressive brands that will draw new, talented developers in. Free food is part of that branding as well.
Buying a promising startup and smothering it with their existing bureaucracy would only hurt their reputation at this point.
This is from anonymous on Quora and is basically my point,
"They are much stingier than you might think. The true award amounts are much smaller than they would like the world to believe. It varies substantially depending on the impact the team and the individual have had, and it can be anywhere from $20K to $100K, with the occasional $1M reportedly given to very senior employees (e.g. the team's director). The awards are typically paid as RSUs and vest over 4 or 5 years."
i.e. not much makes it past the layers of VPs, directors, and front-line managers (all of whom like money very much) to the people who actually made it happen.
That approach will also make their acquisition or acqui-hire decisions easier. Based on recent press, they are supposedly setting aside a portion of their Alibaba proceeds for M&A. "Can we build this in 6 mos? No? Let's go ahead and buy then."
Probably a very good move in that with talent, sometimes you have to box it in so it can break out. Hopefully this blanket rule appraoch will restore focus.
I'd say most projects can be knocked together to a basic proof of concept in a day. However getting it to be able to support 100 million users (as per the article), or even be worth showing takes a lot longer then that.
Keep in mind that is the outer bounds. I am sure no one would complain If a team delivered a quality product in some fraction of that six months time period. Even more, though six months sounds like an eternity to a startup with 7 months of "financial runway", for teams used to the bureaucratic pace of yahoo, 6 months is likely considered to be breakneck.
The first "version" could be the wrong term. I'd be asking how long did it take for the first "user facing version" to be produced. I imagine 6 months isnt far off, maybe less but it would be a very restricted beta.
Every week this looks more like a stealth takeover by Google, with Mayer as an advance agent grooming Yahoo for assimilation. Or just some healthy spread of Google cukture across the industry.
I'd wager on "beginning of the end". Shake up large projects until only the smaller, "quick wins" remain, then sell off the assets. It's easier that way from what I hear.
-- Dr Linda Lewis (Columbia University College of Physicians & Surgeons)
Google has been working on their automatic car tech for ~5 years. Amazon has been working on the kindle line for ~7 years. Google's project glass took ~4 years and they've been working on social for ~3 years. SpaceX on the falcon for ~5 years and Tesla Motors on the roadster for ~7 years.
Sometimes the better thing to do is quite literally do nothing before you go pull off a Nokia like move (sucking up to the losing horse in mobile) or the like. That doesn't mean pull a RIMM either.
This kind of thinking isn't very good because it completely disregards the uncertainty present in product development (http://en.wikipedia.org/wiki/How_Doctors_Think#Disregard_of_...).