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.  :-)