RSS
 

Archive for the ‘Software Development’ Category

The Voice of the Customer

Regardless of the industry you are in, one of the best ways to inject the customers’ points of view into a product is to expose those people who are designing and building the product to the customers’ pain. The best way I’ve found to do this is to put them on the support lines for one day every year.

I was reminded of this while on vacation in Los Angeles where I stepped in to help my sister’s company, which puts on music festivals, with an overload of customer issues. It was the first time since 1995 that I’ve been on the phone lines, and it was a good reminder that the customer pain should be our pain. When you are on the phone with a customer, your top priority becomes resolving that customer’s problem and ensuring they hang up happy with your product.

This experience teaches us much more than how to resolve a customer’s problem after the product is already being used. Interacting with the end users is beneficial for everyone in your organisation.

Product Managers benefit from acting as Support personnel for a day because it is up to the product manager to be the Voice of the Customer in all product lifecycle decisions. If the product doesn’t delight the users, the customers won’t be willing to upgrade, recommend to friends, or continue engaging with the product. Planning a product roadmap without exposure to the customers and users is a risky approach. Even worse is product design by committee rather than bringing the voices of actual customers and users into the design cycle. Realizing that your customers dont want or need the product you’ve created is very costly to the company.

Developers aren’t often exposed to the users of their software, but with the proliferation of methodologies such as Agile and Lean, many more of the design and implementation decisions for a product are being put in the hands of developers. It is critical, then, that the developers have a deep understanding of how the users engage with the software. It is much cheaper and less risky to design and implement functionality in ways the users can understand when that area of the product is first being engineered then it is to go back and make changes later.

Quality Assurance engineers and software testers should, in my opinion, be required to spend one day every two months on the support lines as they are the Voice of the Customer when it comes to both usability and overall quality. In the beginning stages of a product development lifecycle, when test plans and test cases are being written, QA managers will not be able to accurately prioritize and estimate schedules or staff without understanding the pain points of the customers. We all know that QA won’t have time to run all test cases or usage scenarios, but they can at least prioritize the most frequent user scenarios if they are faced with that customer in need. Immediately after product release, QA engineers staffing support lines will be able to get an indication of what issues need to be fixed in a patch release or update, and how urgent those fixes are to the users.

Even managers and executives should get their hands dirty on the support lines on occasion to remind themselves that the customers are real people. There are few activities within a company that can expose the senior staff to the customers’ joy in the product and their pain. This will also enable the executives to understand how investment in the quality of the product can have a knock-on effect through lower support costs, higher uptake in user adoption, and a more accurate prioritization of investment in the areas of the product that the customers use.

So get on those phone lines, online chats, and emails. Get to know the users and become their voice.

Share
 

Unconventional Talent Acquisition

I’ve recently been exposed to the concept of educational technology as a method of assisting with talent acquisition when I was introduced to BraveNewTalent.com. It got me thinking about how a hungry candidate (sometimes both figuratively and literally) can gain entrance into the technological workforce without the required education credentials. 

This struck a very personal chord with me as I have been able to advance to a VP position without having obtained a university degree. Not only was education far too expensive in the US, I also had to start working at the age of 14 to help support the family in addition to attending school. For myself and many people I knew, the need to earn a salary trumped the need for an education. It was only down to luck, therefore, that my geeky side pushed me to learning how to program computers for fun starting at the age of 11. But without a university degree, getting a job in technology was destined to remain a pipe dream in my mind.

After working three jobs to pay for Uni, I dropped out and pursued my career at the time of hotel management. One of the regular guests at the hotel mentioned that with my obvious love of technology and proficiency in fixing guests’ computers, I would have a promising career in software companies. It was then that I started to think seriously about trying to break into the software industry despite having no formal degree.

As BraveNewTalent.com is doing, Powell’s Technical Books in Portland, Oregon also makes possible. I began spending my evenings and weekend at Powells with stacks of technical books, reading them from front to back, until I felt confident enough to pursue full-time work in the software development world. What Powell’s Technical Bookstore made possible for the local community, BraveNewTalent is making possible for the entire world. For someone who is hungry for entry into the world of technology (or management, or marketing, or anything really), there is training material and guidance by professionals and companies helping to expand the candidates’ knowledge and competitiveness in the business world.

A year ago I hired a bloke who also had no degree and no experience in our field, but he was hungry enough to self-study about software development. One of the best decisions I’ve made as a hiring manager was to take a chance on this guy. While he still has a lot to learn (don’t we all), he was passionate enough about the business to study on his own and continue studying after being hired into our company to ensure that he was able to excel at his new job. 

I believe very strongly that while it is important to hire well-educated technologists, it is also very beneficial to hire those candidates who are passionate enough about technology to self-study and strive for positions that are made available through increasing their knowledge in their chosen subjects. Through websites such as BraveNewTalent, the trend of universities such as M.I.T., Stanford and Berkeley putting their lectures online, and the bookstores such as Powell’s Technical making information accessible by anyone hungry enough for it, we are sure to grow the worldwide talent pool, accelerate innovation, and maybe change a few lives in the process.

Share
 

Checkpoints When Outsourcing

I have been fortunate enough over the years to work for some exciting software companies. Many of my favourite are, sadly, no longer with us. When looking back over why some of these companies failed, there are a surprising number of similarities (hopefully unrelated to my employment with them).

The first software company that I worked for fulltime was a brilliant little company in Portland, Oregon called Now Software. We were the biggest Mac-only software company in the world in the early 1990s and counted among our customers the US Government and NASA.

Our products included Now Up-to-Date and Now Contact, client/server-based scheduling and contact sharing applications that could still rival Outlook today. We also had a very popular Macintosh system utilities product called Now Utilities that were very useful little productivity and system personalisation tools. We acquired our competitors, Touchbase Pro, and were the first to have a handheld PDA calendar and contact syncing software solution for both Apple Newton and Palm.

The culture of Now Software was one of fun, supportive people. We had nerf gun wars, Quake tournaments using the intercom to communicate across the building, and the occasional office dog keeping us all on our toes. Many of our customers who would call our support department sent us gifts as thanks for helping them. It was a very nice atmosphere and my favourite place to work.

At the MacWorld Expo every year, Now Software had a large presence, and we always had crowds of customers coming by to engage with our technical staff.

When a new CEO came on board and decided to branch out into the Microsoft Windows market with new client versions of Now Up-to-Date and Now Contact, he did what many companies do: made decisions on investment and implementation without having his technical team perform due diligence on the technologies. He raised a round of venture capital, hired a VP of Engineering from Intel, and told him to ‘Make It Happen’. Because the development team were all Macintosh developers, the VP of Engineering outsourced the development work for the Windows client and the lack of communication between his outsourced team and the existing development team caused a mentality of ‘Us and Them’ to permeate the company.

The mistake so often made, though, that was certainly the point of failure in this situation, was the lack of Quality Assurance Checkpoints in the development process.  QA Checkpoints are stage gates in the product development process where a build of the application is given to QA and tests are run to ensure that the functionality is compatible with the rest of the solution. In this case, the servers that shared calendar and contact data across multiple users’ machines (clients) required the data to be shared in a specific structure (as any data warehouse would) and the communications needed to match what was on the Mac-based server and the Mac-based clients for seamless back and forth transfer of data.

There are may ways to avoid falling into this trap.

First, using a development methodology that allows for testing at regular intervals, such as Agile SCRUM, means that the QA team can test from the very beginning and fatal problems can be identified before progressing too far down the development schedule. With Agile, the development and QA teams are ideally sitting together and in regular communication with their daily standups, so there are few surprises.

Next, schedule code reviews between the team doing the new work and the team who knows the other portions of the product. Code reviews might be seen as soon as invitations to critique coding style, but that is not meant to be the case and that behaviour should not be tolerated. Rather, code reviews provide an opportunity to ensure that the developers are writing the software to work most efficiently with the code written by other developers once integration occurs.

Finally, do not invest such a large amount of money into a project that it could bring down a healthy company if that project fails to sell. Even with QA checkpoints and code reviews ensuring that the software will work as expected, without a selling product the rest of the successful products are put at risk if the company has taken too high a risk for too little reward.

Unfortunately Now Software did not have sufficient QA Checkpoints in place with the outsourced agency doing the work on a Windows client. It wasn’t until the final product was delivered to our home office and the money had all been spent that it was discovered the Windows client didn’t communicate correctly with the server. Some wonderful products disappeared from the market because of these very preventable mistakes.

It was this example of how quality assurance, or the lack thereof, can impact the health of an entire company that convinced me to go into that field back in 1996 by joining Microsoft after the firesale of Now Software. If you are looking for an exciting career of playing with puzzles, quality assurance would be an excellent area to try. And campaign for QA checkpoints!

Share