This is the fourth in a series of posts on Agile Marketing – the working definition of which is to “Create, communicate and deliver unique value to an always-changing consumer (or business) in an always-changing market with an always-changing product.” See the original post here. We know that we’re always promising something along the lines of “I think that will be shipping with our next release.” The best way to help your Agile Marketing efforts is to Just Ship It.
Agile Marketing Principle #4: Working Software is the Principal Measure of Progress
People only know that you’ve made progress when they can see for themselves how things have changed. Notice that the headline above doesn’t say “finished software,” but instead says “working software.” This is a critical notion that makes some product managers quite nervous because they measure progress by looking backwards after they’ve finished, not by measuring whether users can achieve the tasks and stories the users want to do with the “not-quite-finished” software.
Working software generates progress because people can measure the difference between how they want to use the software and what it actually does. Even though the rounded corners on the UI may not be done, the point at which the software works (or alternately, requires the user to do something that doesn’t make sense to them) is the key turning point that drives user adoption. (Note: you might need to finish your software to the nth degree to make your users ecstatically happy. But I don’t think that rule applies to the 80% of users who only use 20% of your features.)
If we accept that working software is the principal measure of progress, it means that both internal and external users of your software need to know how things are supposed to work for the most common use cases and why they work that way. It also means that fewer, more easily understood features usually trump increased functionality and edge cases (for the 80% “good-enough” user). Finally, when you do deliver “the next version” of the feature, it will feel like incremental, easily understood progress to the user, rather than a brand new set of cases to learn and master.
How then, can you make “the way things work” most consistent, understood, and discoverable? You can increase consistency in your product by having a glossary of terms and actions, describing both the nouns of your product (what is that thing I’m looking at?), the verbs (what should I be trying to do here?), and the overall grammar (now that I understand what it is and what it does, how can I make a new activity with that thing and expect it to turn out in a way that seems familiar?).
You can make the product better understood by asking, speaking with, and listening to your customers. It’s neat that a team can find really great ways to use its own product, but if the customer (because the customer is not you) can’t figure out what they’re supposed to be doing or how to do the things they want to do, your product will never gain wide adoption (which, by the way, might be ok if you price it correctly.) Also, figure out the easiest ways for your customers to get help (it’s usually to call or email you directly.)
Consistency, discoverability, and ways to get help – then you can ship even when it’s working, but not yet finished. And use your customer feedback to take it from working to finished – you’ll know and your customers will know how you are progressing if the software you deliver just works (or is very clearly described so that they can make it work)
Information Maven 
Leave a comment