Thought Leadership


Subscribe to our blog

Your email:

Connect with Ness

Software Engineering Services Blog

Current Articles | RSS Feed RSS Feed

Program delivery day isn't the end, it's just the beginning


race showing start and finish lines side by side

by Ron Miller
Ness Blogger 

You and your development team have been working hard. Delivery day is around the corner. You've probably had more than your share of all-nighters making that final push to get the project done. And when it's finally out the door, your team sits back with a sigh of relief and a bit of justified pride that it's over. Or is it?

Ray Velez, chief technology officer at Razorfish who was speaking at the Digital Pulse Summit in Boston this week said you need to rethink how you look at the delivery, not as the end of the process, but as just the start.

Velez said this is easier for shops that already practicing agile programming because you're stopping every couple of weeks and reviewing where you are. You tend to iterate, rather than build all at once, but if you're not doing that, it's going to take a change in mindset.

You need to learn what people like. People tend to build way more functionality than they need into applications (and products in general) because they think about everything people might use, but in many cases people aren't using whole swaths of functionality and that's a waste of your resources and your customer's time.

Velez says companies need to move to a customer-centric approach to development. Don't think because you put your heart and soul into the product idea and worked countless hours helping to build it that you understand the needs of your customer.He encourages the use of product managers, whose job is to balance the sometimes conflicting  requirements of the business and the customer.

And he says to let data drive your decisions. You can think you know what the customer wants, but if you check the data and see which pages they visited or which functions they used most, you may find your gut was wrong and you just have to accept that.

He believes by building your projects iteratively over time, you can reduce building products you think people want and you can begining build ones that people actually use because it has the features that they need the most to do a particular job.

This is in fact, the way Yammer works. They are constantly building new iterations and use data to analyze if people are using the new features. As Yammer puts it, "When we build Yammer, each feature is broken down into a set of hypotheses, and each of those hypotheses is tested individually. By incrementally developing features and using data to validate each hypothesis before making further assumptions."

They have a clear data-driven incremental development methodology that strives to take the needs of their user customers into account, even if those needs change over time. They are never left flat-footed by changes to the market because they are always in a position to shift and change if their customer needs require it.

You can't possibly meet the needs of your customers if you are trying to develop a product roadmap and then sticking rigidly to it because by the time you finish the product, you're probably already delivering something that your customers might not need.

That's why you need to step back and rethink your approach to development, if you haven't done that already and work from the customer back, not from the product back. And if you think delivery is the end of the job, you're dead wrong. It's just the start.

Photo Credit:  Dru Bloomfield - At Home in Scottsdale on Flickr. Used under Creative Commons license.

blog comments powered by Disqus