When I think about "making" software, the first activities that come to mind are design and construction. But there's so much more, including customer and market research, release planning, feature description and specification, construction oversight, alpha and beta testing, implementer and support training, market rollout, and early adopter support.
All those activities can be harmonized and improved by choosing the right goal. Here are a few examples:
Making Products for the User's Entire Experience
I've observed increases in product adoption and satisfaction when makers orchestrate the user's entire experience, and design products to succeed in each phase of the experience. Here's an example of a successful experience:
Select → Acquire → Implement → Use → Improve → Upgrade
Orchestration goals include eliminating surprises and delays in each phase, and reducing the effort needed to move from one phase to the next. This requires coordination of practitioners throughout the maker's organization (including product managers, functional and user interface designers, usability engineers, software architects and engineers, license and contract managers, marketers, sales representatives, provisioning managers, implementers, and support engineers).
Design goals depend on phase - for example:
- Select Clearly telegraph usefulness and reliability during demos. (Good looks never hurt either!)
- Acquire Make it easy to license the product and download the assets needed. How does design enter into this? Consider a modular product: functional similarity or incompatibility between modules make acquisition harder.
- Implement Many single-user products make implementation simple: just a one-click install and a minute or two of preference-setting. But when implementation must be more complex, self-guidance and diagnostics become valuable.
- Use This is familiar territory to most product makers; key questions often include: Is the product easy to learn? Easy to use? Satisfying? Reliable?
- Improve Give users ways to accelerate and enrich the actions performed most often, automate processes, and expand the product's uses.
- Upgrade This is also familiar territory to most makers; some common goals are accomodating legacy functionality and offering backward compatibility.
Enterprise Products Have Different Needs
Most of us have daily experience with single-user products, like email and web clients, word processors and spreadsheets. But how many spend a similar amount of time using enterprise products? The differences are pronounced; here are just a few:
- Many users are only occasional visitors, so information display and decision making must be kept simple; but frequent users and power users need access to high-efficiency tools in order to be productive. All three kinds of users must be accomodated.
- Users are likely to face huge volumes of data, so they need automation that lets them focus quickly and repeatably.
- Teams of users are prone to creating silos and then duplicating others' efforts, so managers must be able to share data and synchronize activity.
- Each user's business is different, so products must be modular and allow fast integration; implementation experts must be available; and customization must be supported, and retained during upgrades.
- Products are often installed in shared environments and administered by personnel who are seeing them for the first time, so fault tolerance, persistence and diagnostics are needed.
- Selection of a product is often a multi-year process, so products must hold to long-term feature roadmaps.
Even enterprise product makers usually spend much more time using single-user products than enterprise ones. There's a constant danger of making decisions based on what's most familiar, so teams need to reacquaint themselves frequently with the needs of enterprise products.