Imagine that you are in South America celebrating your wedding anniversary. Because pottery is a great local tradition and you want your spouse to receive the best possible gift, you have asked two of the most accomplished potters in town to sculpt you a clay vase. The first one views the task at hand as a project. He promptly asks you what the vase should look like and when you need it to be finished, warning you that the more complex the vase, the more expensive it will be. After that, he simply tells you to return in a few hours and pick it up.
The second potter, on the other hand, has his eyes set on the final product. After hearing what you have in mind, he asks questions about your spouse to determine how they normally decorate the house, their favourite colours and even their general likes and dislikes. The potter then makes a few design suggestions of his own, and after you have both agreed on a final plan, lets you know when the vase should be ready before handing you his number in case the final product needs a repaint or mending.
In the end, you are a lot more likely to be happy with the second potter’s vase; and this is very similar to what happens with software engineering. While most companies view the development process as a project, that is, a piece of planned work with a particular start and end date, some like Software Planet Group believe a product-based approach is the best way to safeguard success.
Regrettably, over time, even customers have been conditioned to see development as a project. In practice, however, this translates to little more than developers being focused on implementing features, keeping down costs, ensuring quality control and adhering to project deadlines. Although there may be nothing wrong with any of these individual priorities, together, they expose a gross negligence towards the future of products.
This is because the model, which is typical of many companies, places so much importance on schedules and results that the final piece of software is likely to be rushed and rarely amounts to something users truly need.
By contrast, companies with a product-based mindset act primarily as partners. In addition to the priorities spelled out above, working hand in hand with customers, they hone in on marketing, design, user experience and the real-life issues facing a target audience in order to solve tangible problems and ensure lasting relevance to the market.
This is why all SPG product managers are expected to have a broad understanding of a customer’s business. Without this pivotal factor, they would be unable to provide teams with the necessary context for design, development and deployment. But of course, in order for this process to work as intended, customers must also be willing to become active participants in development. As a reward, they reap the benefits of seeing their feedback being put into practice at all times.
And this partnership does not have to end with software release. After deployment, Software Planet Group are prepared to provide customers with all the necessary support for future maintenance and further development. While the first potter expected his customer to be happy with his own interpretation of the vase, the second one was able to craft the perfect gift for his customer’s better half. Much in the same way, project-based software companies may deliver what you ask of them, but a product-driven partnership offers the best chance to produce software solutions your users will love, and never forget.
