다음을 통해 공유

Build the right feature, build the feature right!

  • 아티클

So one of the key responsibilities of a Program Manager at Microsoft is to drive features. Features are the same as functions in some software nomenclature, and essentially, they map to something the software performs to satisfy a customer need.

Now, over the course of my career as a software engineer, I’ve seen two major disconnects in product teams. The first is where product teams never seem to be able to pick the right features to build. They have great talent, amazingly smart people, lots of resources, but just no direction, so they end up with awesome software that no one wants. I’ve also seen the opposite, teams with great feature lists, but a lack of diligence and professionalism required to ship quality features, so they build a product everyone wants but no one can use or will pay money for. This has led me to distill a little saying which has always held me in good stead: build the right feature, build the feature right. What does that even mean?

Well, knowing what features to build is an art in itself. When building a global product, it’s not easy to simply ask your customers what features you should build. Instead you have to use different techniques to ascertain what features are valuable to them, and which are not. You need to take into account multiple inputs, such as focus groups, customer visits, user feedback, market movements and pressures, and insights into areas of possible innovation. By doing this, you make sure that all the hard work the developers will do to produce your feature, is worthwhile not only to the customer, but to the business too.

Now once you’ve worked out the right features, you need to work out how to build those features right. See, this is where I’ve seen many a software group come unstuck. Picking a good feature is only half the battle, delivering it with quality and style is another. For example, in order to ship a great feature, many factors need to be considered, such as how the customer intends to use the feature, how the customer would like to use the feature, the best way to design the feature so the customer can be efficient and comfortable in using it, and can leverage existing skills and experience to be productive. It’s not good enough to simply cut some code, there needs to be a quality process from design through to deployment to ensure the feature is rock solid and appealing to the customer.

Shipping great software is about embracing both of these aspects, not just one of the other.

Technorati Tags: Building Products

Comments