23Jan

The Voice of the Customer

Posted by: elan Categories: Product Management Quality Assurance Software Development Usability
No comments

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 don’t 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.

Tags:
24Aug

Chasing The Sale = Chasing Your Tail?

Posted by: elan Categories: Product Management Software Development
No comments

Anyone who has worked with me over the past few years will be familiar with my strong opinions regarding the importance of solid product management in a software development company.  I admit, when I first thought about going into marketing, I thought that marketing’s role was to support the sales campaigns. It took one specific product management course, Pragmatic Marketing, to enlighten me, and I’ve been a convert ever since.

If you read nothing else about product management, read the second half of page 5 in this presentation by Steve Johnson. It is a story we’re all familiar with, we occasionally need reminding of, and could make or break a company.

Basically, when you create software in your garage with your mates hoping to be the next Jobs/Wozniak or Gates/Allen, you’re creating what you believe to be a cool product that will revolutionise the world. But will people actually want it enough to pay money for it?

Once you start forming a company around your cool product, your sales people will sell it like crazy, but chances are the chasing of the sale will result in having to customise your cool product for every customer which makes the success of the company precarious due to slim profit margins.

Instead, by hiring a product manager who can research and identify what the market as a whole needs and wants (and most importantly: will pay money for), you can sell the one product many times rather than chasing your tail in a vicious cycle of selling many products once.

Tags:
27Jun

Defining Your Product

Posted by: elan Categories: Product Management Software Development
No comments

Whether you work in product management, marketing, or sales, a good problem statement can be very beneficial in helping to define, market, or sell your products.

The other day a product idea was pitched to me which, when described verbally, was one of those ideas that was very complex and difficult to explain. It began to feel like a maze of features which not only overwhelmed me, but bored me. I rapidly lost interest and started to think about other things.

If this sounds like a reaction you often see in your product teams, customers, or stakeholders, then you might need to think about tightening up your message.

I started working with the client to simplify the explanation of the business model enough that people hearing about it would not get overwhelmed.

This was the perfect scenario for a problem statement.

For anyone who doesn’t know what a problem statement is, it is the basic problem that the market is experiencing which you feel you can solve with a product.

Writing a problem statement is not an easy task. I have found that it works best as a very simple statement without caveats or descriptions. When I ask someone to write a problem statement the first time, they invariably try to use their solution as the problem.

Bad Problem Statement: “Cambridge needs to create a congestion zone and charge drivers for driving within that zone.”

By using their solution as the problem statement, they have not only avoided acknowledging the actual problem they are trying to solve, but they have essentially ended any discussion around how to solve the core problem. If the audience doesn’t agree with their solution, there is no empathy remaining around the need to solve the problem that still remains.

Good Problem Statement: “Traffic into Cambridge can come to a standstill, usually in the mornings.”

A good problem statement explains in very basic terms what the core problem is. With luck, this results in an ‘A-ha!’ reaction in the audience which is critical if you wish to guide them down the right path towards creating the right product or selecting your product as their solution.

Real World Case Study

Chances are that the makers of Google didn’t sit down and say “lets build a search engine” just for fun. They probably first identified a problem in the market such as “finding anything on the web is difficult.” Their solution was “build a search engine.”

Now that the problem statement and solution statement have been sorted out, it is a good time to begin listing the features and benefits of your solution. This is another situation where people often mistake one concept for another. Your feature is not inherently a benefit, and the benefits that your solution provides don’t count as features.

I prefer to list the features and benefits in table format with features in the left column and benefits in the right column, each benefit aligned with a specific feature. The hypothetical Google features and benefits might read:

Problem: “Finding anything on the web is difficult.”

Solution: “Build a search engine.”

  • Feature #1: Robots scour the internet for words and phrases
  • Benefit: Website owners do not need to submit their sites for inclusion into search results
  • Benefit: The latest versions of website are always searchable
  • Feature #2: Words and phrases on the internet are indexed into a database of results
  • Benefit: Searches can occur fast and results displayed almost immediately

If you take this example and use it as a template, keep an eye on how often you find yourself writing a solution in the problem field or a benefit in the features field. After a bit of practice, you can get your product idea clearly defined and communicated.

Tags:
12Jun

Affordable Usability Tests

Posted by: elan Categories: Product Management Software Development Usability
No comments

 

There is a common question asked in most companies I’ve gone to work for, and that is “How do we make software that people enjoy using?”

Well, I have news for you. Most people (me excluded) don’t like using software. Unless we are all lucky enough to do all of our work on an iPad, we’re going to experience varying degrees of frustration with the software we have to use, and we’ll avoid using software that is not an absolute necessity to our livelihood.

So how does a software company counteract the frustration most users feel towards their computers but still release products that users will buy?

Usability tests.

Have representative users come in and try out a prototype of your software concept. This will save you time in your development process, ensure you’re getting it right the first time, and help you to keep support costs down post-launch by making sure the software is easy enough to use that people don’t have to contact your company with ‘how-to’ questions.

There are many different approaches to usability testing, but you can do casual studies with 1 week and a simple mock-up on the cheap, or formal studies with a dedicated usability lab, cameras, screen capture, and an audience of developers. I’ve even done successful usability tests in a corner of a tradeshow booth. Even a small amount of qualitative or quantitative user data is going to save you time and avoid HCI design problems later in the development cycle when changes become more expensive.

A very simplified description of a usability test consists of:

  1. Create a semi-functional prototype with key features active in a Flash-based or HTML5-based mockup
  2. Write a list of tasks to be completed by the user (i.e. new file, make changes, save file, open changed file)
  3. Make note of where the user tries to click to achieve their goal and where they get confused
  4. Interview them and find out their thoughts on the experience

A few weeks spent on this effort pays off in the long run by giving you a product that people can use while allowing your engineers to design and develop features once without having to go back and redo their work.

For more information and guidance on running affordable usability tests, visit the presentation on Slideshare ‘Usability For All Budgets’

Please get in touch if you would like help in setting up your usability testing processes.

Tags:
7Jun

What drives your software company?

Posted by: elan Categories: Product Management Software Development
No comments

In my many years working with software development companies, I’ve seen three distinct types of leadership, each with its own challenges. The leadership tends to evolve along a consistent path within each company, and some companies survive these transitions while others don’t.

Most software companies start out as a technology-driven company. This means that a few brilliant engineers got together and created a cool product. Quite often when this happens, there is excitement around the technologies within the tech world, a round of investment will be raised, and a few sales are made. The management team, usually made up of the founding engineers, ramp up the employee base, create more and more cool products, and hope they sell enough to cover the company costs. Generally the headcount will rise to between 100 – 300 employees, there will be one large customer not-quite-covering the development costs of each product (if they’re lucky), and fixes to products are performed and delivered to customers quickly. As the company grows, however, it soon becomes obvious that there are more products than customers and the overhead on those products ends up being quite high as there are customisations unique to each customer that need to be maintained in separate code braches. The customers become more demanding without a willingness to pay suitable maintenance costs to cover the cost of developing the customised product.

Many of these companies will be taken over by new leadership in the form of a new CEO, new board members, and maybe a few new management team members. The board of directors will be becoming impatient at this point for higher revenues, so often the new CEO will have a strong sales background. The company will now suddenly be a sales-led organisation. The new management team will want to go through a cost-cutting exercise to please the investors as well as generate as much revenue, quarter-on-quarter, as possible without as much of a long-term strategic focus. They will talk about long term strategy because this is what they strive for, but the focus on short-term revenue will pull the development teams from product to product in order to deliver whatever it is that the sales team has promised the customer. There will be initial discussions around reducing the number of products being developed, but the fear of saying no to any customer, no matter how low revenue the deal is, will mean that the product lines will stay alive and continue to be developed according to what the customer asks for. The development teams will be pulled off of a product midway through the development cycle to respond quickly to a customer request, and long-term strategic projects will flounder while short-term requests are met. Many key developers will leave the company at this point because the excitement of creating something new and innovative has been lost. The sales team will make deals based on revenue rather than on profits, and there will be a consistent quarterly panic to meet the revenue targets even when each deal will cost the company more to develop than they will recognise in revenue.

With any luck, the companies will last until they evolve into a market-driven organisation. This type of organisation tends to have a much longer strategic outlook. There will be fear among the staff of more processes, but processes, when done right, are generally made to make things easier and more stable. Unlike the sales-led organisation, the goal here is to create fewer products and sell them to many customers. To do this, there needs to be strong product management. The product manager needs to own the product rather than letting the sales team or development team own it. neither of those other teams will like to hear this because they had been in charge for so long, it will be uncomfortable for them to not be making the decisions any longer.

The first step is to review the product lines within the company. Break them out into cash cows, future star products, and those products that are struggling to cover their costs. Next, map out the strengths and weaknesses of the technologies, the staff, and the products. Finally, do the same for the competition. The next step is to analyse the market to identify the problems that people are experiencing in the area where your technologies exist. Identify the market problems, and you will see an opportunity to solve those problems with the technical expertise within your company. This will require travel, so the travel budget needs to be opened up a bit despite the fear of spending money that the company will be experiencing right now. The product managers will need to go to industry trade shows to see what is happening in the market, meet analysts in the area, and network with existing or potential customers. Immediate follow-up with potential customers with a request to visit them not on a sales mission but on a potential partnership mission is imperative. Once you understand the market, the problems in the market, the trends people are talking about, and the customer problems, you can go back to your team and develop a solution. Do not be afraid to ‘End of Life’ a product! If the products are not valuable enough to customers, then they are not valuable enough for you to continue investing in them at the cost of more sellable products.

The key is to make sure that the solution solves real problems for as many customers as possible, thereby generating repeatable long-term revenue while keeping costs low and developers happy. Your investors will thank you.

For more information, please visit the related presentation on Slideshare

Tags:
17May

Outsourcing: Is It Right For You?

Posted by: elan Categories: Product Management Software Development
No comments

It comes as no surprise to any of us that the offshoring of software development and testing efforts has become the standard for most companies. But what drives that decision, and how does a company determine if it is the right choice for them? Once a company has been outsourcing for a while, what steps can help them to determine if it is working in their best interests?

When I joined my current company, we had a development and quality assurance (QA) office in India. To the money people, this sounded like a smart idea since the staff salaries in emerging markets can be quite low. While I had my own experiences to draw upon that told me this was a risky strategy, I only had subjective evidence that it wasn’t the best option for this company. Subjective arguments don’t go very far with the people who are managing the costs of a company.

In order to do an objective, fact-based review of the offshoring strategy for my company, the Director of Development (himself a big fan of outsourcing) and I put in place an Agile SCRUM development environment and tools that showed what people were working on, how much time is was taking them, and how many bugs were raised against their code. This system was used by the software developers and testers both onshore and offshore, and after a year the statistics were available to enable us to make an educated analysis of the success of our offshoring strategy.

Understanding the Challenges

The first step I took when performing the review after a year of offshore analysis was to identify the efficiency issues that existed due to the remote teams. The employees we had working for us in India were absolutely love people and tried very hard, but it became apparent that with their remote location there were challenges that no amount of dedication and good intentions could overcome.

Challenges:

  • High Staff Turnover – In emerging markets, the fast-growing job market means that as staff are trained on new technologies, they can use those new skills to get a higher-paying job in another company. The trend in many offshoring centres such as India is a new title being awarded each year, and employees generally leaving their company after three years (on average) to pursue a new role. What this means for a company is that there is a risk to training up employees or in relying on offshore engineers for long-term specialist knowledge. Essentially it becomes a risk to train your teams to perform the work you need them to do.
  • Remote teams make reactive testing difficult – For offshore testing of projects that are developed onshore, there becomes a need for detailed test plans to be written covering every feature, environment and user scenario. The training of the testers becomes an additional burden as does the management of priority of testing efforts and recognising what has been tested and what hasn’t.
  • Agile development requires geographically close teams – ?With Agile development, the potential for faster turnaround of higher quality code can be achieved, but only with highly integrated development and test teams. ?The personalities that can make Agile work must be highly independent developers and testers who do not need complete documentation prior to doing their work. With the requirement for detailed documentation for making offshoring work, there is an immediate roadblock to making Agile work.

Understanding the Team

In a report titled “Rebalancing Your Organization’s Agility and Discipline” [PDF] by  Barry Boehm and Richard Turner, there is an efficiency grading metric that helps to identify how adaptable team members will be to an Agile environment. The Manager making these decisions needs to take the time to get to know the developers and testers as well as becoming very familiar with the work performed by each employee.

Table 2. Levels of Software Method Understanding and Use

Level Characteristics
3 Able to revise a method (break its rules) to fit an unprecedented new situation
2 Able to tailor a method to fit a precedented new situation
1A With training, able to perform discretionary method steps (e.g., sizing stories to fit increments, composing patterns, compound refactoring, complex COTS integration). With experience can become Level 2.
1B With training, able to perform procedural method steps (e.g. coding a simple method, simple refactoring, following coding standards and CM procedures, running tests). With experience can master some Level 1A skills.
-1 May have technical skills, but unable or unwilling to collaborate or follow shared methods.

(copied from “Rebalancing Your Organization’s Agility and Discipline” [PDF] by  Barry Boehm and Richard Turner)

After getting to know my team and the work they each performed, I was able to apply these efficiency levels to each of them. The team members working onshore were mostly level 3 with a few level 2s which menat that they were able to work independently and without strict direction whereas the offshore team was averaging around a level 1B or -1 which required a bit more direct management.

Cost of Doing Business Overseas

The next step in determining if offshoring is costing the company more than the savings in salary costs is to identify the additional costs of doing business overseas. In order to make an offshoring strategy successful, a company needs to send the highly-skilled onshore engineers and testers with specialist domain knowledge down to teh offshore location for training at least twice a year. Reviewing the travel costs as well as the cost of these specialised team members not performing their own work is critical. Next, an onshore and an offshore manager need to manage the relationships, ensure that the necessary documentation is being written, the training requirements are understood and addressed, and the knowledge transfers are taking place. Other costs to review are redundant systems such as hardware for test labs, automation testing equipment, software licenses, and test suites. Finally, calculate the amount of time that the onshore team members lose from their own work by needing to mentor the offshore team. This mentoring overhead usually requires between 10% – 20% of the onshore and offshore team’s time which can become quite expensive.

The argument for offshoring almost always stems from teh argument that salaries are lower in the emerging markets, however the rapidly increasing job markets in these offshore hubs are driving the salaries higher at an alarming rate. Many companies have been transitioning their offshore efforts from India to China, but according to GIS Jobs Survey 2010 and Hayes Salary Guide 2010 the costs of doing business in China are on par with doing business in India.

Making the Tough Decisions

After a year of looking at this question objectively, my company came to the conclusion that the practice of offshoring our development and testing efforts were costing us for more than we were saving. We made the controversial decision to close down our India office and spend the measurable costs on hiring fewer developers and testers into our onshore location. This decision was taken over a year ago now, we’ve had the team working in our UK office for one year, and the difference in our products has been truly spectacular. Our developers and quality assurance engineers work very well together as a team, they respond to customer requests quickly, and the feedback we are getting on our products from the past year has been very exciting. We are now creating really ground-breaking products with very fast turnaround, rapid adoption of new technologies, lower support costs due to improved testing and usability, and higher sales due to very satisfied customers.

Tags:
27Apr

Write Once, Print Often

Posted by: elan Categories: Product Management Software Development
No comments

A wise man once taught me that there is no need to write and rewrite and write again the marketing collateral for websites, brochures, and flyers for a product. In fact, consistency across marketing collateral goes a very long way towards communicating complex product descriptions and value propositions to customers, market analysts and sales teams.

I had first experienced the impact of writing canonical text in 2006 when I was working for a highly-technical company and was trying to find ways to communicate clearly what the different products did, how they related to each other, and why they would solve the customers’ problems.

The first thing that stood out when we began to review our collateral was that there was an awful lot of text on every webpage, brochure and flyer. And the text on each of these items was completely different from the others. This meant that the marketing teams were rewriting the text for every piece of marketing material relating to each product. It confused the sales teams and market analysts, and it certainly confused our customers.

The leader of our marketing department decided to have us write canonical text for every product in our division. He had us begin by writing a problem statement for each product (see my previous post titled “What is your Problem?”. The problem statement helped to clarify the basic value proposition of the product.

Because the problem statement included a list of features and benefits, an elevator pitch for each product became much easier to put together. This is a description of the product that you could tell someone during an elevator ride. For some products, this is a remarkable difficult achievement!

As pieces of sales collateral needed to be written with more detail, such as flyers, brochures, and seminar slidesets, the canonical text proved to be a very good starting point. Each piece of material that was written with more detail could be tailored to the audience, whether it needed to be more technical for seminars or at a laymen’s level like websites and flyers. This helped to ensure the message was consistent across audiences.

We then proceeded to expand this text into a website where we needed images – in this case screenshots. As part of the canonical text exercise, we chose a very small number of screenshots, graphs and graphics that would be relevant, interesting, and easy to reuse. Like the canonical text, these images were the same across all of the marketing collateral for each product. Make certain to save them as high-resolution the first time as recreating them for printed brochures is not fun.

By finessing all of the marketing material in the department in this way, we found that we were able to respond much more quickly to marketing needs, we were much more confident in our external communication, and our sales department and customers finally understood what we were talking about. Well, most of the time.

Tags:
3Feb

Taking Desktop Software to Mobile Devices

Posted by: elan Categories: Software Development Usability
No comments

Many traditional software companies are reviewing options for taking their products to the mobile space, but how can you be certain you’re bringing the right features to the mobile audience?  The first and most critical question you need to answer is “What are my customers trying to achieve with this software on their smartphone or tablet?”

The first step in determining the functionality to take to a mobile device is understanding the different types of user behaviour for each device.

Desktop Software

Users are comfortable with long hours spent creating and editing documents on their desktop computers.

Each user has most likely set up their system exactly how they prefer, making interaction as comfortable for them as possible.

Usage

  • Creating & editing documents
  • Interacting with multiple systems

Attributes

  • Keyboard & mouse driven
  • Large screens
  • Powerful CPU & video card
  • Lots of storage
  • Multiple windows

 

Apps on Tablets

Tablet devices are more powerful then ever, and with the BYOD trend, workers across many sectors are adopting them for daily tasks.

Users on tablets are prone to short attention spans and expect fewer steps to achieve their goals.

Usage

  • Reviewing documents
  • Light system interaction

Attributes

  • Touch driven
  • Mid-size, high quality screens
  • Fast CPU & GPU
  • Challenges with power consumption
  • Single window

 

Apps on Smartphones

We all realise that the days of only using mobile phones for phone calls are gone. In some countries, web usage on smartphones has surpassed that on desktop PCs.

Users on smartphones expect to be able to perform small tasks quickly, and applications often have to be aware of each other (camera, social media).

Usage

  • Sending short messages
  • Completing small tasks

Attributes

  • Touch & button driven
  • Small screens
  • CPU & GPU
  • Challenges with power consumption
  • Single window

 

Case Study: Evernote

When choosing the features from your desktop application that you wish to implement on tablets and smartphones, it might help to look at some other products that have successfully made that leap. For this example, I will use Evernote, a brilliant note-taking application that allows users to take notes on any device and have them automatically synchronise across all of their other devices.

Screenshot of Evernote on the Desktop

Evernote application running on a tablet

Evernote on the Tablet

Evernote running on an iPhone

Evernote on the Smartphone
The desktop version of Evernote is feature-rich.

Users are expected to create, edit & organise notes and notebooks

 

 The iPad version has fewer features than the desktop version.

Users are expected to create and edit notes, but not organise.

 

 Evernote on mobile phones is aimed towards basic use.

Panes have their own view with simple functionality

 

 

The best way to ensure that you are taking the correct set of features to your mobile version of your software is to run usage studies at the beginning of the development cycle and again late in the development cycle. Launching a product is expensive and first impressions are key, so make sure that you are providing the best product you can at initial launch.
To learn more, view my Going Native presentation on Slideshare

Tags:
28Jun

Checkpoints When Outsourcing

Posted by: elan Categories: Product Management Software Development
No comments

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!

Tags:
1May

What They Need, Not What They Want

Posted by: elan Categories: Product Management Software Development
No comments

WARNING: This is the most deeply technical of my posts so far. You might want to have an aspirin ready.

One of the things I’ve learned over the years is that when you create a software product, it is important to identify a market problem and provide a solution to the market for that problem. This is slightly different from the approach many of us take which is to find out what the customer wants and provide them with what they want. This often isn’t solving their problem at all but is merely giving them features that they think they need.

I was lucky enough to sink my teeth into my first product management role at ARM with the RealView Profiler tool. This product is something that took a concept that’s been around for a while (and even available as open source in some manner) and figured out how the existing products in the market were failing to answer the problem that software developers were looking to solve. Notably, the existing profiling tools for embedded software could only profile milliseconds of software execution without resorting to software annotation or instrumentation of the hardware. This didn’t give the software develoeprs an accurate measure of real-world usage of their software.

<supergeekmode> Imagine, for instance, that you are writing the user interface for an internet-enabled TV. You need to ensure that the code you’re writing will fit in the footprint of the embedded system and that the amount of runtime memory required to run the software will fit within the amount of RAM available to you while at the same time ensuring that performance of the user interface and all other functions (video stream) aren’t impacted. </supergeekmode>

Obviously, only being able to measure this for a few milliseconds of application runtime isn’t going to do you much good in terms of measuring size and performance from the users’ point of view, and annotating the code or instrumenting the hardware to give you longer duration results won’t be an accurate representation of what the user will see.

Therefore, the solution to the market problem was to create a long-duration code profiler that can analyse the fully-optimised production software.

Still reading? I’m impressed!

So how do you achieve this? Well, our technical geniuses worked it out and I can’t share the details. Needless to say, it involved some impressively innovative thinking.

What I can tell you, though, is how much fun it was to launch this product all over the world and see people’s reactions, whether they were customers or competitors, when they realised the possibilities. We created an incredibly easy to use product for them that made their optimisation attempts fast and accurate and comprehensive. And because I care about such things, we made it pretty as well.

Here is an article about the launch of the version that supports optimising applications running on mobile phones running Symbian OS

Tags: