“Product development will always outstrip our understanding of risk, but there is a lot we can do to narrow that gap.” – Andrew Maynard.
Let’s start by saying what this blog is not – it’s not a primer on what goes into creating or evolving a new software product. Our domain is software product development for our many customers. Our mandate is clear – take the product concept in the head (and heart) of the customer, and breathe life into it. The customer knows what the product should do, once ready, and we know how to get it to a stage where it can do just that. The aim is to make the customer successful.
So, in this post, we will talk about some of the key things we focus on while going about converting these product ideas into functioning software products. These are our guiding principles, our key considerations, always to be kept in mind, during the architecture, development, and testing of these software products.
Software products intended for general release are just different in the levels of reliability they demand. The product should work exactly as the end-user expects, ie. exactly “as advertised” and there can be no surprises. An extension of reliability is performance. The end-user expects the product to perform at (or better) than the specified level – just as fast and consuming only just the amount of resources specified. There is no room for error or ambiguity. This also places a greater onus on the testing / QA function – “customer found” defects can be a product-killer so a “zero tolerance” approach, or as close to that as can be practically achieved, is mandatory.
This is the time of the consumer internet and the mobile-first approach. The end-user is used to a highly functional, extremely intuitive, easy-to-understand and easier-to-use product. They no longer care for the colorless, text-heavy, multi-click, user-interfaces from 5 years ago. Products that engage the attention of the end-user are likely to be adopted more and used more and this has to become a key consideration in their design, development, and testing.
Everybody wants to their product to be successful. Success means many more users, perhaps even a flood of new users if yours is a product on the web or a SaaS product. When (not if) this success arrives – will the product be ready to take it? Can it accommodate a lot more users or a surge of additional usage requests within a short span of time? In these days of the on-demand cloud, chances are the infrastructure will not be a challenge, but can the product scale to a multi-server, multi-tenant environment, at the needed pace?
Talking about the Cloud, inevitably brings with it questions of security. The cloud is sometimes a dangerous place. Products on the cloud run the gauntlet of security threats from hackers and competitors every day. It is not just mala fide intent that they need to worry about, security vulnerabilities introduced due to limitations of the base technology used or the cloud infrastructure the product relies on, or even mistakes by the end-user are all potential openings to worry about. The product design, development, and testing have to anticipate such threats and address them.
Often the folks coming up with the idea of the product are not technology people – as we said earlier, they know what the product should do for the end-users but not really how to go about doing it. It is up to us, while charting the course that will bring that product to life, to innovate at every possible opportunity. We seek to draw all the possible juice the chosen technology approach has to offer so the process of efficient, economical and effective. We look to build the fastest way to develop the product. We try to bring in learnings from other fields and apply them, if relevant. Our developers usually embed themselves into the customer organization and this helps them to start thinking of those small tweaks that can help move the whole product development process along while keeping the end objectives in mind.
Speed is the order of the day in product development. No idea is completely unique and the end-user the product we are building is looking to serve, is always in the market for viable options. This means that the onus is on us to define a product development approach that gets a version of the product out into the market, even if it is with a curtailed set of functionalities, in the shortest possible time. It is up to us to approach the most appropriate model that enables this to happen. This could be the MVP approach with a release-fast, get feedback and iterate often model. We could follow an Agile development methodology with several sprints and multiple releases or, in the case of the Cloud and SaaS product this could be the DevOps way, with releases at even shorter intervals. The go-to-market strategy of the product defines the approach and this feeds into everything else we do along the way.
Paolo Caroli had made an interesting observation a while ago about the process of software product development that still resonates with us. He is reported to have said, “Software development is the process of creating a computer software. It includes preparing a design, coding the program, and fixing the bugs. The final goal of software development is to translate user needs to software product, while continuously improving the team and the process.” With each product we develop, we get the opportunity to grow and become better. Has the process of building software products helped you similarly? How did you go about that task?