Home > Custom Development, General Software Development, ISV, Software Development > A Developer’s Uphill Journey From Custom Development to Software Vendor – Part 2

A Developer’s Uphill Journey From Custom Development to Software Vendor – Part 2

Jonathan Cogley: From Custom Development to Software ISV

February 26th 2009 | Jonathan Cogley

We concluded our last blog post by posing a question about meeting customer requirements in an off-the-shelf software product:

So, how can we bring customers into the software development loop and meet their real world needs?

There are things you can do as an ISV (Independent Software Vendor) to bridge the gap between the development team generating requirements and somehow involving the customer.

You can come up with personas for typical users of your new software and categorize their likes, dislikes, favorite colors and even foodstuffs, but it is all fantasy until you have your first customers. Another option advocated by many vendors is an early access beta program; this helps to build a community around your product in the early stages and provides valuable feedback from people using your product. This option is still not ideal since the characteristics of a beta tester may not match the profile of your typical customer in six months time. At this point, the cynics are probably saying that this whole situation isn’t that different from custom development projects, since their user requirements can be poorly defined or championed too.

Our approach was to focus on the pain that our product solves. Secret Server is a web-based application to store passwords in an encrypted database and then securely share them with other team members (or your wife for that matter!) By delivering the core pain-relieving features, we would have a product that was genuinely useful and could then be refined and tuned based on customer feedback. This strategy put our product in our customers’ hands quickly, solved a few of their main problems, and began generating a stream of feedback to then drive requirements for the next phase. In fact, our tracking system actually prioritizes issues and features requested by our customers.

In our custom development, we always practiced what we call “just good enough.” This means giving the client just what they asked for in the shortest possible time while avoiding any over-engineering (read: technical guessing). This mentality was useful for our initial product development since we could easily have blue-skied the product into non-delivery. Focus on the pain your product solves and deliver it quickly to get early customer feedback.

Aesthetics Count!

First impressions count when the user has a choice about using your software. This impacts the aesthetics and the quality of the user experience. Gone are the developer-designed user interfaces, as they simply can’t compare to the work that a true graphics designer can produce in a few hours. The implications of this decision were huge for our development team. The developers knew that a qualified professional would beautify the interface later on, so they could ignore aesthetics and focus on the functionality and automated unit testing (test-driven development) of the software. I have seen developers spend hours tweaking a user interface on many custom development projects because no budget was available for a dedicated graphic designer. This costly exercise seldom produces remarkable results. The decision to use a professional early on benefited the overall output tremendously.

The user experience isn’t just pretty graphics, though, and the vendor should spend serious time refining the number of clicks to perform tasks, the information presented on the screen and the metaphors used in understanding the system. This difficult and time-consuming task can be justified, since the results will be spread over the many users who will try and, hopefully, use your software. Small gains in usability can yield large rewards when marketed to the masses; the economics of this attention to detail do not pan out when there are only a small number of users for your software.

Next week’s blog will explain how stability and virtualization play a vital role in quality assurance.


Jonathan Cogley is the founder and CEO of Thycotic Software. Test Driven Development (TDD) is the cornerstone of the Thycotic approach to software development and the company is committed to innovate TDD on the Microsoft .NET platform with new techniques and tools. Jonathan is an active member in the developer community and speaks regularly at various .NET User Groups, conferences and code camps across the US. Jonathan is recognized by Microsoft as an MVP for C# and has also been invited to join the select group of the ASPInsiders who have interactions with the product teams at Microsoft.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: