Software Engineering, Project Management, and Effectiveness
How can you differentiate what you do? This can be particularly difficult in problem spaces that seem over-crowded. It helps if you have a frame. One of my mentors gave me a useful lens for differentiating that helps solve this problem.
Problem, Approach, or Implementation You can differentiate based on problem, approach or implementation:
If you differentiate at the problem you solve, it's good to be able to call that out. If you solve the same problem, but use a different approach, unless it produces a big difference in results, it's probably not worth it. If you differ only by implementation and the experience or results aren't valued by the customer, again, it's probably not worth it.
Using the Frame for Differentiation First identify whether you differentiate at the problem, approach, or implementation. Next, determine whether the level at which you're differentiating is worth it. For example, consider safety among automobile makers. Volvo's approach to safety stands out. They work the same problem but differentiate by approach.
By having clarity around where you differentiate, it's easier to communicate your deltas in a meaningful way to others.
Example At Microsoft, when I tackle a problem that's been "solved" before, I use the frame as a lens to quickly find the useful differentiation. For example, doing security reviews wasn't a new problem. However, changing the approach by using inspections and building a set of reusable criteria from a team of experts changed the game. By using criteria based on principles and patterns, and then organizing the criteria within a frame of actionable categories produced exponential results for all of our customers that adopted the approach. Old problem, new approach, great results.
PingBack from http://blogtester.gamerslegacy.net/?p=3913