RSS
 

The Voice of the Customer

13 Dec

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.

 

Taking Desktop Software to Mobile Devices

03 Aug

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 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

 
No Comments

Posted in iPad

 

Checkpoints When Outsourcing

28 Jun

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!

 

Outsourcing: A False Economy?

17 May

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.

 

What drives your software company?

07 Jun

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

 

Write Once, Print Often

27 Oct

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.

 

What is your problem?

20 Oct

The other day my husband and I were in the middle of a long drive when we started discussing one of his business ideas. When described verbally, it was one of those ideas that was very complex and difficult to explain. We started thinking about how 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.

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

When I ask someone to write a problem statement, 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.

Using Google as an example, 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.

 

It’s Not About the Features

02 Oct

Something that many companies miss is that the success of a piece of software is not necessarily based on the features, nor is the success of hardware based on the technology inside. Instead, it is most often the pleasure of using software on a computer or device that drives adoption and leads to a product’s success.

How many users do you know who say “I love my HTC TytnII mobile phone. It has an ARM CPU in it which can be very powerful”?

Answer: Zero.

Outside of ARM’s employee base, I would wager that this sentence has never been uttered. When asked about how they like their Tytn, I’ve heard people respond with “it is too difficult to find what I am looking for” or “It is slow”. Similarly, the Nokia phones have traditionally been the market leaders in Europe, but time and again, despite the leading edge technology inside, the thing people focus on the most is the difficult user interface which often requires 8 clicks to do something that could only require two clicks.

There have been many astounding advances in hardware technology that should have made our devices such as televisions, mobile phones and laptops snowball into futuristic gadgets, but there is a chasm between the hardware technologies in a device and the software being written to exploit all this power. One example is graphics processing units (GPU). For years, high-end computers have had GPUs in their systems for driving video games and mathematical rendering, but now GPUs are entering the embedded space.

About this, users don’t care.

Where this gets interesting, though, is when software developers are trained on the programming languages specific to the GPUs and can really take advantage of the speed and power provided to them.

Still, users don’t care.

It is only when the user interface designers, software developers, and product managers work together that any of this becomes remotely relevant to the end users.

As an example, look at my favourite subjects, the iPad and the iPhone. Why do people love these devices? It isn’t because of the incredibly powerful CPUs in sided. It isn’t the GPUs inside. And it isn’t even the features. The users love these devices because the experience of using them is fun.

There is an emotional reaction to using these products that spans generations, cultures and lifestyles. Part of generating an emotional response is to be responsive and reactive enough that the excitement level doesn’t dissipate (no slow rendering). Another aspect of an emotional attachment is safety or absence of fear (the user cant break anything).

The users don’t care about the guts of the machine. They don’t care that the software developers wrote the graphics rendering code in OpenGL ES or DirectX to take advantage of the GPU. They don’t even care if you loaded the hardware or software with features or left everything simple.

The users care about the experience.

 

Simplicity in Software is the Future

25 Aug

Yesterday I had lunch with a 3 year old (as well as various other adults) and pulled out the trusty iPad to help with entertainment and distraction. This might make you cringe at the thought of a sticky, fidgety little munchkin defacing such a gorgeous piece of electronics, but I had my trusty rubberised (washable) case on the iPad which has proven invaluable in the past when contending with my unimpressive gracefulness.

What struck me, though, was the speed with which the three year old was able to figure out how to interact with the iPad. That in itself was astounding, but even more remarkable than that was the ease that the child had in using the various applications that were presented to him.

I had previously downloaded apps such as My First Words, Insects HD, Bubbles, and iFish Pond to inspire children of friends of mine, and they are simple but interactive apps that engage a child’s mind. The key elements that make these apps worth paying for are the simplicity of them, the obvious purpose of them from the moment they are opened, and the inability for the user to do anything wrong within the application.

In this age of small, simple component software rather than the complex, behemoth applications of the 90s, this ease of use is going to become the element that makes or breaks a software product’s future. The days of a software application needing to be everything to everyone are fading fast.

These days more non-technical people are using computers than ever before. It is virtually impossible to get through daily life without a computer. Yet most software applications and operating systems still expect users to understand non-intuitive technical concepts in order to achieve simple objectives.

I believe that the key to success for a software company is to make things simple and easy, avoid adding too may features and options, and simplify. Apple has gotten it right once again, and if we are up to the challenge, the rest of the world can embrace the concept and make technology fun for everyone.

And here goes the remainder of your day:

 
 

Chasing the Sale = Chasing the Tail?

24 Aug

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.