Tag
product management

Farhad Manjoo writes in Pando Daily about how Dropbox is just a feature. Unfortunately the examples he talks about seem to support the exact opposite.

Someday, someone will figure out how to make this sort of thing work well, but I suspect it will most likely be one of the companies that makes a major operating system: Either Apple, Microsoft, or Google. Each of these firms has a file-storage and/or syncing solution that it’s pushing, and I expect that those efforts—iCloud, Skydrive, Google’s Chrome syncing and perhaps the mythical Gdrive—will gradually incorporate more and more of the features I’m looking for.

This assertion is about as wrong as could be. Earlier in the piece Farhad talks about how things just plain worked as Dropbox synced things from his Windows desktop to his Macbook Air. What are the odds of Apple getting their sync client right for PC's? Just about zero, considering what they've done in the past with MobileMe sync.

Same goes for Microsoft writing sync software for the Apple platform. Arguably Google is in the best shape to provide a seamless multiplatform experience... well, except for iOS! The odds of a viable multi-platform option emerging from one of these big three seem slim to me.

The truth is none of these behemoths will execute perfectly on this scenario in the way Dropbox (with no ulterior platform motive) can.

Dropbox is probably working to build many of these features as well. But as third-party app, it’s just not in a very good technical position to do so. In order to sync programs and window states, Dropbox would need access to some of the deeper parts of my various gadgets’ OSes. This is easy for some operating systems and impossible with others—including iOS and probably Amazon’s Kindle Fire. Apple could easily build a way to sync the current browser tabs between my Mac and my iPhone, so that I can switch from reading Pando on my couch to reading it on the train. Dropbox will need to go through incredible hacks to achieve the same functionality, and it probably won’t manage to do so even then.

Sadly Farhad is just wrong on this too. Getting native bare-metal access is easy to get on every platform that matters except iOS. On iOS, Dropbox *already* has a huge lead on all of the other file syncing platforms by virtue of wide support by the developer community. Apple will undoubtedly get some share of iOS developer love, but it is yet to be seen whether Apple will actually unseat Dropbox.

Truthfully, it is foolish to count large platform players out. But my money is on Dropbox. Until Apple wins every last device over (not even a goal of theirs), Microsoft steals the show for mobile and regains share on desktop (highly unlikely), or Google wrests mobile supremacy from the hands of iOS (not going to happen) -- the ongoing platform cold war will assure it's Dropbox that's going to be how we keep our data.

Tags

Part of the deal initially was that Wave would be compensated much like a startup, base salaries were supposed to be low but with heavy performance linked bonuses which would have made the Wave team rich upon Wave's success.

During the course of negotiations and building the Wave product, the "heavily reward for success" part of the equation remained but the "punish upon failure" got gradually watered down into irrelevance, making the entire project a win-win bigger proposition.

Because large parts of the performance bonus were tied to intermediate performance goals, the Wave team was more motivated to hit deadlines than to ship good product. Product began to suffer as the team pushed to fill in a feature checklist on time.

Reflecting on my own time as a program manager at Microsoft early in my career, I have to say the push to ship intermediate milestones and hit dates can have some serious unintended consequences.

The classic software project management quandary rears its ugly head again, over and over, and seemingly everywhere.

Quality, scope, or shipping on time: Choose two.

One thing I disliked about being a PM at Microsoft was how one of the main things we ended up having to do was punt bugs in order to ship on time. We were implicitly and systematically reducing quality and scope in order to ship on time.

If you don't sacrifice quality, then you're sacrificing scope. And doing that mid-stream for a project is often death by a thousand paper cuts, especially for user experience. Product teams end up spending as much time designing to duct tape together incomplete features and broken scenarios as building them in the first place.

And when you don't scale back scope, you sacrifice quality and end up with Google Wave. Damned if you do, damned if you don't.

Tags

The latest much ado about nothing on the Internet: Blogger Joshua Blankenship has written a pot-calling-the-kettle-black diatribe against Dustin Curtis's apparent lack of humility in criticizingAmericanAirlines. He seems to think that Dustin should be a little more humble in his criticisms of such a large, immovable corporation whose complexity seemingly exceeds that of a very good designer.

I call bullshit.

A humble designer is one who affects no change indeed. Designers should be less humble. When engineers or business guys or management or *anyone* makes a product lousier, they should get up and shout, and raise hell. Designers should NOT 'know their place.' Because if the powers that be keep their power, then we will continue to live in a barely working cesspool of compromises and bad experiences.

Apple wins because the guy who cares the most about user experience happens to run the show. And last I checked, humble wasn’t really a word you could use to describe him.

Tags

Google’s dependence on hardware and carrier partners puts the final
product out of their control — and into the control of companies
whose histories have shown them to be incompetent at design and
hostile to users.

Windows Mobile was a failed experiment in relying on hardware vendors, partners, and carriers to build a great consumer device. There were too many cooks in the kitchen. There were too many integration points.

Case in point: Bug fixes from the field. To get a device to market, there was the core device team, then a mobile operator/commercialization team, and finally the carrier's support / deployment team. There was no shared database of bugs. No shared responsibility. When schedules were stretched thin and the device was failing even simple tasks, it was too easy to point fingers. Oh, that's the carrier team's fault. That's the OS team's fault. That's the commercialization team's fault. Hardware's fault. Nobody took the reins to ensure a quality product was being created.

The Palm Pre team is doing it right. Google would do well to take note here. Building cool techie platform toys that let you create nifty Powerpoint decks is all well and good. But it's all a huge waste until there's a satisfied user using your awesome phone that works great.

It comes down to responsibility. Someone has to be responsible. If you're creating a device, and you want it to succeed, it better be you and your team.