Nice lean start up example of “faking it until you make it”, or, in other words, using the people-power before you code it with software:
Anderson’s growth strategy is pretty clever. He has three overseas workers (in India) who will take any bookings made on the app and physically call the salon or restaurant on the user’s behalf, then email the user back to say if their appointment has been successful. This can be a little time consuming – I tried booking a hair appointment on the MyTime website and had to go back and forth to find a good time.
The overseas worker essentially plays two roles: a one-time personal assistant for me, and a sales person for MyTime. Once they have the salon on the phone to book an appointment, they mention that it came through MyTime, before adding, “Would you like us to create a free profile for our app, so we can connect to you calendar?”
It’s not only a good growth strategy, but it’s also a great way to understand the mindset of the businesses you’re working with, the eventual buyers of your software.
We're going to try something on a project we're kicking off here at work: "Agile" programming methodologies in the service of sticky business problems. We're not coders, but we're going to apply what we understand of the approach. We'll use "stories" to get our focus on the problems we need to crack for the marketers we work with, the stories we want to be able to tell when we've solved them. We'll have a list of these stories and work through them one at a time. We'll do that in quick (2 weeks), focused efforts (aka "sprints"). And, we'll if we don't get it right, we'll iterate through them again until we've got it right. We'll be focusing on "shipping", that is getting the project done and implemented. We'll focus less on the beauty of a comprehensive, centrally controlled process (ie. "waterfall), and more on getting working "software" (ie the tools and methods) into the hands of the teams we work with. Lastly, we're going to try to dramatically improve communication via "huddles" and may even try full team huddles to communicate with a much larger audience. The IT group will probably laugh at how we're doing it, but we're going to take a shot and get it right over time if the first efforts aren't spot on.
Any suggestions on how to apply agile programming methods to a non-programming problem?
Updated: 8:30 PM
Lots of good suggestions from folks around the web. For sure, check out Rohn J Millers post on the subject from last year. Lot's of good ideas in there. And, here's a pretty good overview from PJ Shrivasta. Finally, i look forward to re-reading Greg Meyers Agile Marketing Manifesto in a couple months to see how we're doing.