In my last post, I wrote about “value propositions” as one of the key items we received feedback on during our recent Software Design Reviews (SDR). Since we haven’t talked much about the use of value propositions (value props for short) during prior releases, I want to give the concept and practice a little more of introduction than I’ve given them so far.
First, a definition. According to Encarta, a value proposition is:
a statement of the way a business proposes to use its resources to deliver superior value to its customers
Let’s take this definition apart. First, a value prop is “a statement“. In fact, we’re pretty particular about how these statements are written since we regularly compare these to one another and it helps to have them all read generally the same way. The implied beginning of all value props is “Unlike with Visual Studio 2005, what if you could…” It’s instructive to state an objective in this way as it forces you to focus the capabilities (rather than features or technology) and to clearly distinguish how it’s different than our existing products.
Next value props describe “the way a business proposes to use its resources“. A couple interesting points here. First, in terms of using our resources, we leverage value props to organize our planning and execution efforts. For instance, once we settle on the core set of “critical” value props for a release, we use them as the basis for our end-to-end scenario flow which in turn helps inform our planning efforts throughout the organization. Also, these are proposals. As such, they express possibilities for the future and are aspirational in nature. It’s not at this level that we get overly concerned with the implementation or technical considerations. That comes later.
The final portion of the definition is “to deliver superior value to its customers.” This is another critical aspect of value props for us…we really want to focus on the benefits that we can provide customer through our product. While we have a particular implementation in mind as we talk about this, the critical part is what problems we solve for our customers. As such, when talking about value props, we’re very open to various implementations.
During our most recent SDR, there were a number of possible value props that received a lot of attention including:
- Generate compilable, testable baselines for the most pervasive applications (Smart Client, Web, n-tier) or services
- Replay and rewind the events that lead up to an error in pre-production or deployment
- Create functional tests for UI and services by capturing and replaying user interactions automatically
- Enable manual testers to reliably and consistently create actionable bugs for development by enabling testers to take and capture notes, capture screen shots and capture trace information (diagnostics) during tests.
- Create, organize, and manage test cases and results for the entire development organization, and provide traceability from test results to requirements.
- Collaborate with remote, distributed and outsourced teams
- Easily administer TFS
- Trace work, conduct impact analysis and report status against requirements, including reporting on progress, build availability, test pass rate, etc. and seeing the impact of changes to requirements
- Manage work across multiple projects
I’m curious what you think about this list. Based on your usage of Visual Studio and current challenges you and your team face developing software, would you find these valuable? Are there others that you’d find even more valuable? Are there some that seem to have little to no value to you? Of course, I make no promises that we’ll deliver features in these areas in future versions, but instead provide the list to spawn additional discussion.
As we continue to work on future releases, we’ll continually refer to these value props, reprioritize, trim and clarify their meaning to us. In some cases, we’ll scope a general value prop to something more specific for a particular release. Since we have way more of these in mind than we could ever do in the near term, identifying those that are critical for future releases is super important to us. If you could only designate a few of these as being critical, which ones would you choose?
I look forward to hearing back from you.