You’ve decided that you need to develop a software application. Easy enough, all you have to do is hire a programmer right? Wrong. When it comes to successful application development, programmers, no matter how good, aren’t experienced in all of the things that make an application a market-ready product. They don’t know what should go into it, and they don’t know what can go wrong. Programming is only one element on a long list of considerations that includes product design, definition, architecture, user experience, and management – to name a few. In order to develop an application that your customers will like, you need to assemble a team that will ensure your application’s success once it’s released.
What kind of team will you need? Avengers, assemble!
First, let’s start with that word “team.” One person is not a team – we’ve all heard of “the guy who wrote that successful app,” but that’s an outlier that you don’t want to bet your business on. Any serious application development effort requires a multidisciplinary team. How big a team, and how many disciplines, is determined by the scale and nature of your project. Think about these roles and how they fit your project, then assess existing talent, determine what is missing from your team, and address those voids before you write a single line of code.
Here are the basic roles you should consider filling (in order of appearance):
| Product Specialist | This role goes by many names, but this is the person who understands what the product needs to be, who the users are, and what they care about. (In the Agile world, this person is called this the Product Owner.) This person represents the needs of the user/customer in the project, and provides the overall definition of what it is to be. |
| User Experience Designer | Works with users to understand how they think and work, and designs the product to fit that. |
| Architect / Senior Engineer | Makes the critical technical decisions about how the product is to be built. |
| Developer(s) | Write the code, build the product. |
| Quality Assurance | Makes sure the product does what it’s supposed to do, and does it well. |
| Application Security | Makes sure the product is safe, and cannot be made to do things that you don’t want it to do, that can harm your business or your customers. |
It’s possible, on a smaller effort, that some of these roles may be carried out by the same person. Even then, it’s critical that you accept that these roles exist as separate and necessary roles. If you don’t have someone consciously filling each role, then something important will be missing from your product, and it will fail.
Still with me? Then let’s look a bit deeper into the things that these roles are responsible for.
Product Definition
Product definition includes, among other things, the features of the product, competitive analysis, development costs, and product pricing. It’s one function of the larger Product Management function in the organization (see below).
Product definition, however, is much more than a list of features and functions. You should consider product definition as a critical part of usability. What is it supposed to do? What are your customers using it for? Why do they need it? Is it filling a void left by the competition? It’s important to know what they want and why they want it. Ask your customers. Work with the usability expert on your team to interview your customers and define their needs; do not assume or guess. A product definition that includes customer input increases the potential for acceptance once it’s released. In other words, your product will be more likely to sell.
The product specialist may not be responsible for actually doing all of this work, but channels that work to the development team.
Product Management
There is a close relationship between the product specialist, and the Product Management function of the organization. The product specialist often comes from the PM group. Product management encompasses every stage of the product’s lifecycle from strategy to product rollout. The responsibilities of product management are graphically represented in the figure below (provided by Pragmatic Marketing). Managing the stages of product development should not be left to your programmers.
Standards and legal considerations
This is an obvious and often overlooked consideration, and should not be left to your programmers to decide. Are there industry or government standards that need to be met, such as HIPAA or PCI or Sarbanes/Oxley? What is required for your application? Will you need an “accept terms and conditions” button? If so, the terms will need to be reasonable and legally vetted. Have other companies had legal issues with a similar product that need to be addressed before release? Those are product-level questions.
User Experience Design
This is much more than deciding on colors, flow, harmony, and graphics. To be successful, your application needs to be familiar to your user. There are standards set by popular or competing products with respect to consistency in navigation and nomenclature. There are also visual aspects and operational elements that users expect or require to meet their needs. This is considered part of the usability of the application – your user experience designer should be skilled in task and work analysis, human factors, and usability testing. Some organizations go so far as to employ anthropologists for this role.
The success of your application will be driven more by the usability of the product than by any other factor. You really don’t want to develop an application, take it to market, and only to find that it is unusable. Usability homework done up front will alleviate all kinds of problems in the long run.
Architecture
You should have a single person set the technical stage for the product. There are many technical choices to be made, each with a direct impact on how the development project will unfold.These choices should be made deliberately, with the best interests of the business in mind. While your product or project might not be big enough to warrant a capital-A Architect, you at least need an engineer with enough experience to make these decisions wisely.
Don’t take for granted that your programmers know best. Developers often go with what they know because it’s safer to stay within the bounds of their own experience and preferences (or, worse, they opt for the “latest thing” so they can get a chance to try out something new). Programmers can make a very convincing argument for a particular technology (platform or language) while conveniently omitting that another just-as-viable (or even better) technology exists. That’s why you want a more seasoned hand making those decisions.
Considerations regarding architecture should also include:
- How long will this application be viable? Platform choices for a short-lived application versus one that will be around for years or decades are very different.
- What kind of programming, support, and educational resources are there for the platform? You don’t want to get stuck, down the road, searching desperately for a programmer who “still” programs in that Old Platform Language, or be forced to completely rewrite the application in a more recent language, just before your launch date
Every decision you make has ripple effects downstream. Don’t take any of this lightly.
QA, Testing, and Vulnerability Management
No developer writes perfect code, ever. It just doesn’t work that way. Testing is an integral component of any software development effort. Building testing time into each application development project is a must. Someone will be testing your software; if not you, then it will be your customers. That’s not how you want your bugs to be discovered.
Security and vulnerability are also issues you need to consider. There is always the potential of a threat, so it’s critical to understand the probability and your exposure to those threats. If someone hacks into your application, what will they get? In today’s environment, the consequences of security breaches are significant, and you should be able to make the determination of the level and type of security you need when defining your application, not after a breach occurs.
Support
Support is not needed for all applications. But in most cases, you need to address what to do once your application is out in the world and being used. How will you support your customers? Online? Chat? Forums? When deciding, you need to consider what will be cost-effective yet satisfactory for your customers. Then you need to decide who is going to own it.
_________________
As you can see, there is more to application development than just “development.” It truly does take a team, and each member of the team should be a solid contributor to the effort, specialized and experienced in their area. Team members also support each other; they find things that other team members miss as they build, test, and use the application from their perspective. All of this ensures that, when your application “hits the market,” it won’t land with a thud.
If your team operates properly, launching your application will be the beginning of a wonderful journey.
