My Turn: Ten Insane Ideas for Microsoft

It started with the thinkweek paper, then Dare and Adam dissected it, and Mini encouraged us all to post our own ideas for Microsoft.  I like the theme so; here are my ten <insert adjective here> ideas in no particular order.  As my disclaimer states: I retain the right to change my thinking on this list at any time. 


1. The “2 Secrets” Rule
This may sounds like a strange one for a company whose “official blogging policy” is “blog smart”, but that doesn’t mean we can just tell you about everything we are doing.  In fact… for most people here… its hard to figure out just what you can and can’t talk about with customers.  The rest of us just hope we are “smart” enough to figure it out on our own. 


That means there is less talking to customers and therefore less feedback that’s incorporated into the products we build.  So, I propose the “2 secrets” rule.  Every VP must tell their groups what the two protected secrets are and that everything else is fair game to talk to customers about. 


Two is small enough that everyone will remember what’s off-limits and there would probably be even less risk of those two things leaking since everyone would know what they are. 


2. Scale the Frontline
There is an internal program called “frontline” whereby employees spend a week with product support teams either at a customer site or helping with plain-ole phone calls.   Everyone should be required to do this once and, on an ongoing basis, answer at least one customer question per week in forums/newsgroups about our products.  Everyone should also be required to read feedback from their customers for 30 minutes a day through customer blogs and other public sources on a daily basis.  Encourage customer empathy and pain sharing.


3. Bring Back the Towel Service
You know what?  I wouldn’t mind if you took it out of my paycheck like my Pro-Club membership/stay fit benefit.  Only let those of us who want the benefit into the shower rooms.  Then I could be sure I’d have a towel at work if I ever want to go running in the middle of the day or bike to work. 


4. Test All Ads
I don’t know whose idea it was to imply our customers are dinosaurs for using our older products, but I believe that if all these big ad campaigns where trialed internally first and then with a larger group of customers… like our MVPs… we could prevent this in the future.  I dogfood like a champ on most of my computers so I’m generally on the cutting edge, but I just realized that I’m a dinosaurs on one of my home PCs.  Truth is that office just isn’t used that often on that machine and when it is… its not a bad thing to say that the older version works just fine… so does VS 2002!


5. Cut 50% of Marketing Budgets as we know them
It was Jeff Bezos of Amazon who said something along the lines of… if he had a million dollars to spend and the choice between making his products/services better or doing an ad campaign… that he’d pick the product/service improvement.  The choice was advertise like hell or offer free shipping.  There is just no choice there.  Let’s get creative about our marketing and spend the extra money on developer pet projects that could turn into real product innovations or other incentives that give people reasons to upgrade. 


Ok, so now people who work in Marketing have to get creative… spend $600 dollars on a video camera and introduce the world to your product teams through channel9.  Work on getting your teams to blog.  Use your creativity, energy, and time to get your hands dirty and make the products better so you’ll be more likely to sell them to our customers.  Some of the best marketing people I know spend a good deal of their time making the products they support better based on what they hear in the field and the conversations they spark with customers. We need more of these people and less people who set up flashy-fake web sites with customer biographies about people that don’t exist. 


6. Merge the dev and test teams on a project (everybody does both).
Adam’s idea was so good I had to repeat it.  I’ve been a “Software Developer in Testing Lead” before and heard all sorts of crazy ideas on what testing needed to do in order to “keep up” with the pace of product development or ensure a parallel to the developer career path. 


Adam’s right. Don’t worry about those problems. Everyone is responsible for product quality and the code that goes into the product from day one.  Having separate teams only creates divides in the responsibility chain. Some of the best teams I’ve known at Microsoft already worked this way.  And while we’re at it every Program Manager should be required to get their hands dirty with code.


7. Every Microsoft project should be considered “Open Source” for every other MS employee.
The second Adam idea I whole heartedly support.  He suggested that any dev should be able to check into any project, but I would extend this concept slightly. 


Every product at Microsoft should be considered open source fair game for the rest of the company.  This doesn’t mean open source for the world… lets just start with open source within our walls. 🙂 And it goes beyond source code.


It seems strange to people in Devdiv, where we have a public bug database, but there are several Microsoft projects I can’t even get permission to report bugs to their database or view their plans without knowing the special handshake.  Sure, I could e-mail the team, but why should I waste their time by e-mailing them duplicate bugs if I could just add my information to existing reports?  Just make sure I know what your “two secrets” are.


8. Harvest the wisdom of our crowds
There’s a lot of smart people who work here that could be helping leadership set core product strategy, find smart ways to cut costs, and test out potential ad campaigns.  Let’s start seriously investing in internal prediction markets to leverage all the smarts here and encourage people to think about problems outside their own space.  Hey, if nothing else it could do wonders for cross group collaboration.


9. Make more bug databases more public
We’re proving, for Visual Studio, that it is more than possible to open up a public bug database and expect to respond to every bug we receive.  Every group at Microsoft needs to do this and, furthermore, a greater percentage of our bugs need to be public facing.  Unless they fall under the “two secrets” rule no bug (opened internally by a developer or externally by a customer) should be hidden from public view.  We don’t need to be open source for everything to steal a page from their playbook. 


10. Share more source
The 3rd idea I have in common with Adam.  I’ve never gone so far as to suggest that everything should be open, but I think we’re still missing a bunch of opportunities.  I push when and where I can.  🙂

Comments (12)

  1. Darrell says:

    Oh man VS 2002 is VERY painful. Office not so much.

  2. This is the most useful of the lists so far.

    It is also encouraging to see that Microsofties are aware (and publicly acknowledging that they are aware) of Mini 🙂

  3. Eric Newton says:

    You make good points. I see Microsoft becoming very agile in the near future with your suggestions and with whats already happened.

    With the relatively successful VS Community Collaboration, the product is tight. Biggest benefit: EnC for C#… thats a feature that was directly because of community insistence. I believe a couple of other lukewarm features were dropped because nobody in the community thought they were that grand.

    This is a good step because now Microsoft isnt just listening to a select few, but to the developer community that wants to buy good quality software that meets their needs.

  4. MSDNArchive says:

    Ok ok, maybe suggesting you stick with VS 2002 is going a bit too far. I did upgrade all those bits to VS 2003 as soon as we had a beta. 🙂

    Yeah, there’s a lot of us who know about Mini. He’s on my blogroll for sure. I don’t agree with everything he says and in some ways it sort of like watching a train wreck except more fun.

  5. TAG says:

    Strongly agree on Item 5 !!

    MS did a very poor job marketing VS 2005 Betas to REAL customers.

    On one side you put ads everythere asking everybody to install betas, on other side you write in EULA/Readme that this software may trash out your Windows installation.

    I.e. you promote everybody to trash out their PCs !

    So ? What you can do with Item 5 ? Need ideas ?

  6. Norman Diamond says:

    > there are several Microsoft projects I

    > can’t even get permission to report bugs to

    > their database or view their plans without

    > knowing the special handshake

    In the real world Microsoft usually allows victims to report bugs if victims pay 4,200 yen in advance. Surely you could do the same. Surely you won’t because the idea offends you as much as it does me, but you could.

    An exception was eMbedded Visual C++ 3. When the compiler reported an internal error it told me to view a particular Microsoft web page. That page said I could report the bug if I paid US$195 in advance. I didn’t report it.

  7. Norman Diamond says:

    Wednesday, July 27, 2005 6:31 PM by TAG

    > On one side you put ads everythere asking

    > everybody to install betas, on other side

    > you write in EULA/Readme that this software

    > may trash out your Windows installation.

    > I.e. you promote everybody to trash out

    > their PCs !

    Actually I thought that wasn’t a problem. I install betas in virtual machines under Virtual PC 2004.

    The July CTP won’t install though. I think I’ve figured out the reason. Recently I installed a checked build of Windows XP SP2 with plans to use it for testing a driver, but in the meantime it was a pristine environment for trying out a new Visual Studio CTP. I think I’ve figured out that the July CTP depends on Windows Installer 3.1, but contains a version of Windows Installer 3.1 which refuses to install itself onto a checked build, and there’s no available version of Windows Installer 3.1 that would agree to install itself onto a checked build. I’d guess the July CTP would be installable onto a retail build.

    I’m not in the mood at the moment to create another guest machine just for the purpose of playing with the CTP for a few weeks though. I did exactly that for Beta 1 and Beta 2 though.

  8. Anonymous Dev says:

    I don’t think there’s a chance in hell we could successfully merge dev and test. First, our testers have very few technical skills. The half of them who had a bulk title change to SDET because of their level mostly don’t meet the criteria (or even come close). My team has two testers (out of ~20) that I would trust with a writable SD enlistment. Less than half even have a RO enlistment after a year of encouragement.

    Entrusting that team (some of whom are great testers despite a lack of technical skills) with the responsibility to create our products would be a disaster.

    And, finally, this idea ignores the fact that test and dev are different disciplines with different goals. Most testers like testing, not writing code. The good ones have the skills and the degree, but they chose to go into testing rather than development because that’s what they want to do! One of my friends was a tester on a team who did exactly this – they retitled all of their testers as SDEs, and he hates it with a passion.

  9. MSDNArchive says:

    AD: I don’t think this is a change that could happen overnight or with the current group of employees that most teams have. Something like this would take time to avoid the skill issues.

    Regarding disciplines specialties… this is where we might disagree. Show me a dev who can’t effectively test code and I’ll show you some crappy code.

  10. Dave Cortright says:

    I totally agree about scaling the frontline, but what MSFT needs to do is have frontline support people who are full-time MSFT empolyees with stock options that have a stake in the game. It amazes me that Microsoft fully outsources the only human face the company has to most of its customers.

  11. Anon says:

    "9. Make more bug databases more public"

    You really think customers seeing that there are 1000+ bugs is a product is a good thing?

Skip to main content