Background
At Microsoft I developed a reputation for transforming products. I had a history of making big innovations but it was not until Access 2013 that I cemented my reputation. Its not that my earlier projects were not innovative or impactful, they just did not build a reputation because some people at Microsoft did not want these projects to be innovative. Innovation meant change and there is always someone who does not want change or worries about change, or feels change means too much risk, people naturally resist change. Access was no different. People on the team resisted change, our partners inside and outside resisted change, many of our customers resisted change. Everyone wanted the product to be better but for many that did not mean reinvention it meant a new feature here or there but basically the same dying product. Then something happened, my boss, Derek Burney, probably the best leader I ever worked with, said, “Do something that will make the cover of wired magazine”. Then, Derek did something AWESOME, he socialized the goal all the way up to Steve Ballmer and Bill Gates. He put his butt on the line for the transformative effort. This meant for the first time in my career I had support to be a change agent, to innovate big time, all they way to the top. There is no substitute for this level of support and equally important, no substitute for this level of expectation.
Having this level of expectation placed squarely on my shoulders caused me to get creative. I quickly realized to meet this level of expectation would require serious change, serious innovation. But what does that mean? Innovation is one of those green field words used by consultants that basically means “I flip flopped the screen and now you will be successful…” We brainstormed a list of products we felt were truly innovative and transformative, the ubiquitous iPhone, Xerox Parc, Tesla, Nest, etc. and worked through what they all had in common. What we found was every user described them as MAGIC! The first, and often best in a category, these products are universally magic. Magic, which means effortless, intuitive, attractive. You want to build a product that will be an icon of an industry then don’t focus on completeness focus on magic. That is not to say automagic, never focus on that, trying to be automagic will merely piss off users because the automagic algorithm gets it wrong. You want to be smart? Give the user smart defaults that reduce efforts in the most common cases. Spend your time focused on delivering effortless, intuitive, attractive
Situation
Microsoft Access really was your fathers Oldsmobile. The user base had gotten old enough they were literally dying. Leadership was getting changed out every release with each change shifting the vision and the target customer. Because Access is a “developer tool” Office did not allocate designers to the team so the product was stale battleship grey. And finally, the primary revenue engine was the inclusion in Office Pro meaning the product “made” $1b but over 70% of these licenses were naked with no user deriving value from the license.
In short Access was a dying product.
The team was passionate but demoralized. The team needed a new culture, a new vision, even new processes to break out of the old ways. And most importantly they needed a strategy that everyone could understand and rally behind.
Actions
Setting a goal to reinvent a product is easy. Actually delivering on reinvention is hard:
- You have to inspire the team to actually want to do the hard work and make the hard choices to discover, prioritize, and ship magic. You would think this was easy but since magic is inherently different it is therefor risky and many people will resist really delivering magic.
- You have to choose a target customer. Magic is inherently not a solution for every scenario. The team must pick a specific target customer segment. Yes it needs to be broad enough to generate enough demand to build a business but it cannot be to large the core requirements for different subsets of your target.
- You have to understand the customer. in conjunction with picking a target customer you must understand that customer at a very deep level. Their hopes and dreams, their values, their skills, their responsibilities, their customers, etc. Only through understanding will you find magic.
- You have to scope the core scenarios of your target user. You cannot find magic when you include non-core features. They make the interface confusing and they draw valuable resources away from the work to deliver magic. core features are either the features that are used to initiate the process, most often in the process or have the highest value in the process. If a feature is not on this list then either don’t build it or if it is required, put the minimal investment into it. The process we used was called Kano and it really helped us prioritize magic.
- You have to find the magic. Magic is always the same, taking the most common aspects of a users core scenarios and making them EFFORTLESS, INTUATIVE, and ATTRACTIVE. That is it. Once you have scoped your target customer and scoped your features you will find it is easy to design magic. Magic is not complete it is targeted, magic is not automagic it is smart defaults, magic is not discovery or distractions its about delivering on both.
Now that you have defined magic the real magic is actually shipping it…
Once we had magic defined we held an all hands meeting. I know there are agile pundits out there puking all over the idea but it was the all hands meeting that created the pivotal moment in the release. We had to get the team to leave the past behind and put all efforts into making the future a reality. We had to explain the problem, show people a vision to address the problem, convince the team that transformation was possible, and then demonstrate that management was all in, 100% committed. To accomplish this I drew on my years of coaching experience. We set the stage, picked out music, the Monday night football theme, and in my best Brent Musburger imitation I announced the kick off of the Access 2013 release. Then at the end of the music I jumped out from behind the stage with a 1×4 piece of wood that had the word stodgy written on it and I had the dev manager break it with a karate chop. We had similar boards planted throughout the audience and soon we had everyone breaking boards that said things like boring, old, weak, complex, all of the negative words that were used to describe Access, our product. Once we completed our metaphorical breaking of the old ways, we walked the team through high fidelity click throughs of the vision. Now every one new how effortless, intuitive, and attractive the release could be, how close true magic was to their gasp. All they had to do was execute. Finally the leaders of the team came to the front and said the words, Desktop databases are dead! I commit to this team I will do everything in my power to bring this vision to reality! Then we gave the team the option to say it too, without hesitation everyone affirmed the same to the whole team.
It may not be clear from the description but this all hands meeting was the pivot point. This built a foundation for a culture that was so tight knit that people cried when we delivered. It cemented a vision that people were proud to showcase. It painted a story they wanted to follow. That mantra, “desktop databases are dead” rang through the halls everyday and reminded us of our audacious goals.
So what does it take to execute on such an audacious goal?
You have to scope magic. Historically project teams generated a list of features and “cut” down to the budget, this always fails because all people have loss aversion and “cutting” is giving up features you had and now will not. You have all seen this in action, first round of adds/cuts the team takes on too much work and starts delivering on say 5 major initiatives. Then after spending a third to half of the project budget they realize they cannot ship it all and cut down to 3 major initiatives. Then after spending an additional third of the budget they cut another initiative. Finally after spending 85%+ of the project budget they cut one more initiative hoping it will save the release. This process looks like this:
Because the project started 4 initiatives they could not complete they wasted more than 2 1/2 complete initiatives. In other words, if the project leader had not started only 2 initiatives they would have comfortably delivered 3 but because they started 5 they barely delivered 1. If you want to ship magic never cut a single feature flip the process around. Start with all features are cut and then add in only 50% of what you think you can deliver rounding down, in this case 2 initiatives. After 1/3 of the project evaluate if you have space you can and add no more than half of the current scope. 25% of the total budget rounded down or 1 more initiative in this example.
You have to ship magic. In my experience I have had the most luck with 28 day sprints. Literally 4 weeks. Not 30 days, not 1 month, not 25 days. 4 weeks. I found this cadence worked well because of the consistent repetitive cadence it creates. I have tried 2 weeks sprints and they fail because it provides for so little time to plan and ship. I have tried 3 week sprints, this was better than 2 but it created problems because you have to either split the planning and ship weeks in half or split a delivery week in half and while this is not a show stopper it creates unnecessary inefficiencies. I have also tried 6 and it failed because it was simply too long to write code before you had a chance to evaluate and redirect. I have never tried 5 week sprints but I suspect it will also fail due to the length. I have found using a 4 week cadence rocks and it looks like this:
What makes this pattern work?
28 days (20 working days) followed by demos from EVERY feature crew on the last day, call it demo day.
Because the schedule is 20 working days every sprint, modulo any holidays, the team gets amazingly good at knowing where they should be on any given day if they are going to ship on time. You can ask any one on the team what should be happening on, say, day 13 and they will know instantly there are 2 more days of coding so you should be achieving code complete and dropping to test as it will take the last two days to get your code to converge and checked in even if you have been building early and often. Combining the predictable schedule with the accountability of demos drives progress at a very high rate.
Results
This very deliberate approach to reinventing MS Access 2013 delivered a game changing release. This release was influential across Office. Access 2013 ended up being the foundation for all Office programmability in Office 2015 and beyond. It set the design language in place for structured data in Office and really launched the transition to agile for all of Office.
Most importantly it defined magic. Magic is not complete, it is not automagic, it is smart defaults, it is focused, it is effortless, intuitive, and attractive. Go create some magic of your own!
And if you made it this far, here is your reward! Just like an after credits scene in a movie!
The Tao of Todd 