I think of the work we do in Tinkerbox as the crafting of great software products. Products which people will hopefully love to use. To do this, it is helpful to have a framework to talk about how we make products happen. Let’s start by discussing what we want in a product.
A product must first and foremost be something people want. No one is going to use a product that does not provide any value to them. Mostly this value comes from its ability to solve a problem, but there's more to it than that.
How long will the user use the product for?
Another dimension to consider is how much time the product will be useful for. If the product breaks easily or is only able to provide value on occasion, then it is not very useful indeed. So we can also say robustness, reliability, and even maintainability help make a product more desirable because they allow products to provide more value to users over time.
Is this product pleasant to use?
In addition, a big part of what makes a product desirable is how pleasant it is to use. Part of this is how easy it is to use the product, but more importantly, it is how satisfying and delightful the product is to use. This can manifest in many ways, depending on the user as much as the product. Even if a user gets some value from something, the user can still come away with a bad taste in the mouth (victims of bad customer service anyone?). In software, visual aesthetics play a big role, as does a well thought out flow from one screen to the next. All interactions with the product should be considered when thinking about making its user experience (UX) as pleasant (and therefore the product as desirable) as possible.
In addition to being desirable, a product must also be within reach of the user’s ability to make use of it: it must be accessible. Availability is part of this, but an accessible product will also be within the means of the user in terms of cost and other tools/ingredients required to make use of it.
This should be considered the most basic level of accessibility: if people cannot afford the product, then the product might as well not exist to them.
Means of accessibility
Even if they could afford the product (say free software), if they lack the resources to make use of it (because they do not have access to a computer, or the internet), then once more the product fails to benefit the would-be user.
Also, it is worth noting that users often have to learn to use a product before actually using it. The knowledge required to use the product, say knowledge of using the internet, will also affect the accessibility of the product. Therefore, the ease with which a newcomer can pick up and start getting value out of a product is also part of its accessibility.
Making It Happen
To build a product that is truly desirable while being accessible to the target user is not trivial. People write entire books on how to achieve each of these qualities (and sub-qualities). To bring a product to realization, we need time, money, and expertise, all of which are in limited supply. With more capital, we can enlist more help and technical expertise, hopefully allowing us to deliver a desirable product in a shorter amount of time, but the greater the cost of production, the more one has to charge users in order to make up for the spending, which makes the product less accessible.
To complicate things, it is often hard to figure out what people really want from a product. While user testing and focus groups can reduce this uncertainty, most people will only truly know it when they see it. As the party who is attempting to provide this utility to others, there are three parts to what must be done.
Good Product Design is all about satisfying the needs and desires of the users. So, we need to validate our ideas of what the product is supposed to be, against what people want. If the product we are trying to sell does not provide value that people want, the rest doesn't really matter. The product is not truly useful, or not useful enough to enough people. Which is why establishing an avenue to communicate with the people we think will want to use the product is critical.
With this in place, we will have a way to know if what we intend to build (or are already building) is truly something people want. If it's not, then we need to know how to correct and change our ideas. Here we must recognize that the opinions of the Product Owners should always be second to the opinions of the Users of the product (unless the Product Owners are also Users). Only with the feedback and assessment of the people who would use the product can we know if we are going to build something desirable to them.
This forms the bulk of our work in Tinkerbox. Given that we have a way to determine if a product is on the right track, we also need a process for its production. In our software development practice, we have come up with the following:
- We need to know what the user wants (or does not want) and be able to communicate that to the team. The Product Owners are usually responsible for this
- We need to design ways of interacting with the product that would allow users to get what they want. The Product Designers are usually responsible for this, but almost everyone will have ideas how users should interact with the product.
- We need a plan to build and structure the product that will allow the Product Designers’ ideas to be realized. To do this, we introduce the Product Architect role.
- We need to execute the building of the product in order to realize the Product Architects’ ideas of how it should work. The people who do this fulfil the Product Builder role.
One might notice that the success of each part depends on the success of another. Because of this, the entire process should allow for frequent dialogue with everyone involved so that each part can inform the others and avoid conflict. This is crucial, because having to deal with misunderstandings and the problems that arise from lack of communication can be debilitating for everyone involved, and detracts from the actual work of crafting the product.
When Tinkerbox does work for clients, we usually begin with a rough draft of the design and architecture in order to determine the scope of the work to be done. This provides the basis for a rough estimation of how long it would take to craft the product, and how much it would cost.
Ah, the final step (or is it?). This is where the product is shipped and becomes available to the would-be users, initiating the ultimate Product Validation test. This is an absolutely necessary step for any business and might require some technical expertise depending on the medium of delivery.
This is a whole new level of testing, and with the technologies of today, the effectiveness of product delivery can be measured more easily. Tools like Google Analytics, heatmaps, number of downloads of your mobile app on the app store allows you to quantify product testing and make the necessary tweaks to improve your product.
Agile vs. Waterfall: An Aside
Much has been said about the two, but I feel it is useful to place them in the context of what we have been discussing.
In the traditional Waterfall approach, Product Validation, Product Crafting, and Product Delivery are distinct phases that happen in that order exactly once. In the iterative approach, we cycle between Product Validation and Product Crafting until we produce something we are willing to send for Product Delivery. And even after that we might go back and do more iterations.
In the Agile approach, we take the iterative approach and blur the distinction between the Product Validation and Product Crafting phases. Or rather, we aim to shorten the cycle between phases as much as possible. The idea is that we don’t need to wait for the entire product to be complete in order to validate what has been built, and we don’t really need to wait for what has been built to be validated to work on building other independent parts of the product. We also don't need to wait for the entire product to be complete before changing the parts which we already know are not what users want.
An even more agile approach is if Product Validation happens together with Product Crafting by having Users and Product Owners sit as close as possible to the Product Designers, Architects, and Builders. By doing this, we reduce communication overhead and are able to spend less time on building the wrong stuff into a product. This arrangement is of course not feasible in many cases, and can even become disruptive to Product Crafting.
In practice, we strive for an optimum balance that still allows for a fast feedback loop, but not so fast that the phases become too short to accomplish anything meaningful. It should be noted that this requires active participation from either the would-be users of the product and/or the Product Owner(s).
When we build products, we must realize that what we want to accomplish is a desirable and accessible product. Those two attributes are complex and need to be unpacked and understood by the team. Then the actual production must take the limited resources available and perform Product Validation, Crafting, and Delivery. How exactly these three things happen will determine how desirable and accessible the resulting product will be.
By no means have I comprehensively covered all there is to discuss (there are many great books written on these things, but those take time to read). Also, I have admittedly left out the need for marketing efforts to make the product known (a desirable and accessible product will not benefit anyone who does not know about it). But I hope I have provided a useful way to understand the construction side of bringing products to market. Nothing I’ve said here is really new, but it helps to crystallize and reiterate things sometimes. And with that, happy shipping!
Article by Wei-Liang Chew