When you’re developing a product, you’re constantly surrounded by questions like, “How can I improve my product?”, and consequently, “What’s the next step to take?”. There are 2 ways to answer these questions:
- Ask your customers
- Decide yourself
Ask your customers
Asking your customers appears like the better solution: You’re building the product for your customers, so they should know what they need. Unfortunately, they don’t. Henry Ford, the founder of the Ford Motor Company, once said:
If I had asked people what they wanted, they would have said faster horses.
Your customers are biased with current solutions for their problems, that’s why you can’t expect true innovation from them.
It’s your task to innovate, not your customers’. The problem is that you don’t understand your customers’ problems entirely in advance. Your most important task as product developer is to learn to understand your customers better than they understand themselves. Make a hypothesis about what your customers need and then try to prove (or even better: refute) this hypothesis. A hypothesis is always a guess, but you will become better and better at guessing the more you validate.
It’s taken a while for enterprises to realize how best to use social media. Sales metrics, return on marketing investment and ROI don’t often synchronize well with the vocabulary of the early 2010’s social media expert, whose ‘share of voice’, ‘engagement’, and ‘nurturing advocacy’ make smoke come out of the ears of 90% of CFOs.
Here is an example of where things can get weird. My good friend Media Czar (coincidentally also one of the greatest social media and marketing minds of his generation) sums it up nicely in his blog ‘The Magic Bean Lab’. Media Czar points out that most of the metrics and ideas used to describe the effectiveness of social media don’t mean anything. But there are two important measures that don’t often feature prominently enough in any enterprise social media conversation: reducing costs, and increasing sales.
I’m going to focus on reducing costs, because that’s what I know most about.
Continuous Integration and Continuous Deployment are strong concepts in modern software development and specifically useful and necessary for cloud applications. Delivering code continuously keeps the product development agile and allows for fast iterations. Specifically when it comes to SaaS products or services, the way to ship software has to follow the continuous track, delivering new “releases” several times a day. For example, at Quora every commit is submitted to the production system, unless this process is actively suppressed.
Ever decreasing software release cycles also require to rethink the way feedback from real users is gathered. Bimonthly user experience reviews with a selected set of customers are not suitable if new features of a product are published daily. Tools to suggest improvements and to report bugs need to be actively integrated in the product development process, addressing not only a selected group of testers but also includes real users.
This blog post is essentially an extended tutorial, explaining how to set up a 3C software production chain:- Continuous Integration, Continuous Deployment and Continuous Feedback.
We will use Microsoft Visual Studio and deploy directly to Windows Azure (Section 1). After that we connect Microsoft Team Foundation Server Online to our tool chain (Section 2) and subsequently connecting TFS with Windows Azure to establish Continuous Deployment directly from Visual Studio (Section 3). Finally we will add Usersnap to introduce Continuous Feedback to our setup (Section 4).
Since a standard “Hello-World” approach is always disappointing, we decided to create a tweet-wall which displays tweets containing the hashtag #usersnap. Lots of screenshots should provide a step-by-step tutorial to get you started with Visual Studio 2012, Team Foundation Service and Azure and finally Usersnap. There is no need to write code while walking through this tutorial.