A call for the Pre-Market

In Agile development, if the customer has sufficient funding, creating the product should be very rapid.  When the customer is not ready for the product, necessarily, there has to be a lot of hand-holding to prepare them for the change and to train them and their customers on the innovation that is being produced.

Much time is spent talking about agile development and how important it is.  Arguments are made for light documentation but I've found that this really isn't all of the story.

Test-driven development is critical.  But what about test-driven marketing?  Shouldn't most projects be for marketing/sales purposes anyways?  Why would we authorize our software developers to be the ones that approve whether or not the software is complete?

This is my argument for what I call the "pre-market" as in the market before the App Store, the Android Market, the production release, etc.

Agile supports this idea by distinguishing between iterations and releases.  We need to make many iterations on our software before we are prepared to release it.  But what is the framework into which the iterations are released/delivered and what are the tools that we have available to provide feedback on the iterations?  I would suggest that these tools are currently quite limited and I will argue that that the pre-market concept is a next "major wave".

Let me suggest a few features of the pre-market to help us get our heads around it:

• Secure Portal The prototype is shared with the customer(s) in a portal
• In-App Feedback The prototype is instrumented so that feedback can be easily given
• Meta Data Centric The features and screens of the prototype become things on which feedback can hang, so the feedback can roll up
• Central Database All feedback goes to the same central database
• Invitation-Based The users of the portal can (optionally) invite other people to use / view the prototype
• Filtering of Feedback  Product manager can flag what's important for next iteration(s)
• Serves as Backlog The feedback can be filtered and aggregated into future iterations
• Connected Many other features like sourcing of cash and resources could be added to this system

I'm passionate about this type of system and would love to see it come about.  Let's do it!

The value of mobile

The phone: it's in your pocket.  The web, it's in the phone.  

People ask why mobile is different than the web in general and I have several answers to that:

• The web is cold and impersonal.  Although there are portals and accounts and you can log on and such, it's generally "detached" from you.
• The phone is "in your pocket".  It is yours.  You possess it.  The phone is indistinguishable from the software it runs. 
• The phone adds new data dimensions such as notifications, calling, and GPS.  It is attached to the user and ABOUT the user.

People looking to understand their customers need look no further than the phone or mobile device.

3 Ways to Sell Technology

There are three main ways that I can think of to sell technology: 1) via your business analyst / sales team 2) via your designer team and 3) through your developer team.

In trying to attract customers and show them what you can do or start the wheels in motion on the relationship between you two, any of these ways is an option. I'll describe all three and then comment at the end about my opinion.

The first way is to have your sales / business development people do this. These people will not produce working code, prototypes, or designs. They *may* create wireframes to help solidify the design but only that. They will definitely have to record the user needs and objectives. They will have to serve as the product manager and make sure they understand what will fly for the product being produced.

The second way is to have your UI/UX people make some sample screens. They probably should do this from the wireframes produced, but you could have them go work directly with the customer and have them produce from a UI/UX experience. I'll argue that this is not the best way to lead.

The third way you could sell IT work is by having your developer team create working (prototype) software to show the customer what is possible and or some options. I think this makes some sense so that they can better visualize and understand things beyond just wireframes. A step in this direction but not the whole way would be to demonstrate *transitions and flow* between wireframes.

Overall, any of these methods is possible, but I would say that there MUST be a good business analyst / product manager in the beginning to work with the customer on what he/she specifically needs. Once the product concept is clear and understood, then the UI/UX person can come in and make the mockups really good. (You should charge for this). And once the wireframes and product are solid and perhaps the UI/UX person has had a chance to start, then the developer can start producing production code.

There's no one *right* way to do this but there are definitely wrong and wasteful ways. What are your opinions?