It’s been a year since I’ve posted, so I should provide a little context. In my previous job, I ran a team in the Developer Division that was focused on increasing the flow and quality of communication between our customers (developers) and our product teams (the people who build VB, Visual Studio, the .NET Framework, etc.). We drove things like
With that, onto Embedded Windows…
I was inspired to write this (in other words get my blog-posting rear end in gear) by a thread today in the XP Embedded newsgroup today that included these criticisms:
The tools are truly dreadful and so below standard it’s unbelievable
when it comes this type of essential prototyping during optimising an
Not to disparage what MS has achieved in componentising a complex OS
but I would be ashamed being a mega billion $$$ company and shipping
The sad part is that Microsoft would read this and not be concerned.
They would assume its just a few people and not a big deal.
This is the perfect opportunity to talk about where we’re headed with Embedded Windows (I use that term to distinguish it from Windows CE, and to avoid tying it to a particular version of Windows – our charter is long-term, not specific to XP Embedded).
Let me start by acknowledging the validity of the criticism. There are many many things I’ve seen/heard about in the few months that we need to improve on. We’ve underinvested in this product/technology. As a result, things that were (maybe) acceptable in a v1 release are not tolerable when they are still unaddressed a long time later. The only part I disagree with above is that we don’t care. I took this job in part because the company recognizes that we’ve underinvested, is strongly committed to changing this, and has asked us to do what’s needed to make sure we have a very compelling offering in the embedded market. In addition, we have people in our team (Andy Allred is a great example) who have cared deeply about this for along time, who have been frustrated that we haven’t been doing more, and who are now thrilled to have the opportunity to change this.
At a high-level, I have 4 priorities right now – I’ll share them here and I’d love feedback.
1) Build the team’s capacity. Obviously this isn’t going to directly fix any of the problems people point out. But the reality is that we have far more to do than we are currently capable of. To get out of this situation we are growing the team significantly. Again, to the “MS doesn’t care” argument, I’ve been told to go build a great team – in the near term I have all the mgmt support I need and my greatest constraint is finding/bringing on board people who will help us go fast soon. (We’re hiring in all disciplines – dev, test and program management – if you know someone who should be here fixing that problem you are yelling at us about, please point them my way. 🙂) We’ve made good progress in just these three months, but we have a ways to go still.
2) Make existing customers successful in 2006. Another way to say this – address major pain points that are limiting people’s success today. Given that we’re still building the team, we can’t bite off a lot. But I do want to identify a set of things that, for example, make XP embedded systems more expensive to deploy than they need to be, and then address them. The area where I’ve heard consistent feedback is around post-deployment – managing, servicing, upgrading, etc.. These are problems that can cost customers’ customers a lot of money. Upstream in the lifecycle, we’ve gotten a huge amount of feedback about the tools (what prompted the newsgroup thread). I’ll admit to being schizophrenic about these problems. On one hand, some are truly embarrassing and it’s lame not to just fix them. On the other, when I ask customers “which is more important – these tool problems, or these embedded-features or these management issues?” the answer I typically get is “tool improvements are always helpful, but the reality is we are used to them and can live with them – what our business needs is these other things”. Andy pointed out today that there is a difference between some bigger customers who are driving volume, and smaller customers who do a lot of prototyping. It’s an important distinction which we need to remember. My hope is that we can take some small steps on the tools – even just fixing a small number of “top bugs” people complain about would be a start.
3) Respond to
4) Build a long-term roadmap for success. I view the 3 things above as somewhat reactive – we underinvested for a while, so now we need to do the work that didn’t get done during that time. We have to start there and that work alone will keep us busy for a while, but we eventually want to get ahead of the game. There are number of things we want to accomplish in the long run. To pick a couple: We are going to work with Windows to increase the alignment between the mainstream release and the embedded version – my nirvana here is that the embedded build comes out of the build lab simultaneous with desktop Windows, and ships the same day. (We took steps towards this with
I took this job knowing that in the short-term I’d be hearing a lot of (valid) criticism and that it would be some time until the delay between “Customer points out an issue” and “We address the issue” is reasonable. The thing we have going for us is a lot of mgmt support, and a (growing) number of people in the team who are very excited to be able to show that we do care, that we are capable of delivering a high-quality experience, and that Windows is a great technology base for the embedded market. I realize that it will be some time before we prove ourselves. The one thing I ask until then is that people keep giving us the feedback because we’re finally setting ourselves up so we can address it.
Speaking of which, we do plan to bring over some of the things from DevDiv – for example Product Feedback Center-style feedback (which puts the feedback out in the public, lets customers vote on what is most important, and forces – through internal tools – us to respond with an outcome) or the Forums (which don’t scroll away as newsgroups do and which have some other strengths). Look for that to start happening in the next few months – in my last job I found out you can’t just turn those on, the team has to be ready to do the work. In the mean time, you can reach us through my blog here, through the XP Embedded Team Blog, or via firstname.lastname@example.org. Or the newsgroup that got this started 🙂
Every day I come to work thinking “There are 100 things we really should do today – which one thing should I focus on so that it happens?” And to some extent the answer every day is “Hire one more person into the team”. But with every person we hire, our ability to do work that customers see increases. Look for that to start being visible soon.