Am I Implementing the Right Technology for My New Product?
This article covers question 3 of 5 from the series: ‘Getting Started with a New (Software) Product’. You can access the rest of it here.
When creating a product, the technology you choose can have a profound impact its success. To explain why, we should start with its most fundamental role — to be reliable. For better context, I like to relate new software development to a building’s construction. If your product idea is the foundation of this proverbial building, the technology you implement is its skeletal structure. You shouldn’t worry about how fancy or futuristic it is on the inside (often tried and tested development methods are preferred unless something new is warranted), rather you should be concerned with how well it is built. Technology is not the star of the show; it is meant to do its job without being noticed. Because, however useful or attractive your product may be, if it has stability issues (i.e. it often bugs out or crashes), customers would loose trust in it quickly.
Technology’s next contribution towards your product’s success is to fulfill its long-term goals (or strategy). To understand this more, let’s look at the macro picture:
Your goals can be purely based on economics. For example, many mobile game developers have flocked to Apple’s iOS platform. This is owing to the fact that Apple users have been found to be more willing to pay for apps. But it goes much deeper. The manufacturer’s relatively concise hardware portfolio means that games can be optimized for (and are likely to run well on) a majority of its devices, which in turn results in better app ratings and a higher likelihood of attracting more buyers. This makes for an overall lucrative market for the gaming industry.
Your goals can also be to meet legacy obligations. This is especially relevant in the B2B market, in which companies are slow to adopt to newer technologies. You may want to choose a technology that runs on an older browser; or be barebones in design and features so as to run on specialized hardware (e.g. older HHT devices); or even to be able to interface with legacy systems.
Alternatively, your technology choices can result from a marketing strategy. This can work wonders, like in the case of Netflix, which shifted from a rental to online streaming model by investing heavily in a novel technology for its time. It can also backfire. An interesting case (and a cautionary tail) is that of India’s largest e-commerce retailer in the fashion segment, Myntra. Back in 2015, the company shut down its desktop website in order to drive adoption of its mobile application. This was regarded as a huge risk, especially since smartphone penetration in India at the time was low. And within little over a year, the company relaunched its website to cater to the sizeable slice of consumers who did not wish to shop on their phones. Even though most e-commerce companies now focus heavily on their apps, they still supplement them with desktop websites. Maybe the mobile-only strategy pushed by Myntra was simply ahead of its time and in five years we see it being implemented again (this time with more success).
You may have noticed, the above discussion was more about the platform (or distribution channel) of your product. This is because your selection of the programming language, data structure and visualization tools (what you actually think of as technology) will be dependent on where and how you ultimately sell it. You need to be sure of that before you choose the underpinnings of your product, because they are often interdependent.
With that out of the way, let us get to the specific technology related questions you should ask before developing your new product:
What should I begin developing in a (possibly) large product?
This has an objective answer — a minimum viable product.
Think about the basics first. At this stage of development you do not know if your product would succeed, which is why most mature teams do not invest more energy than what is essential.
Even keep the technology you use simple and basic. If you can build an MVP without complex technologies, that could save wasted time and investment. If you need go all-in, consider what some companies do by releasing their app on one platform (to gauge traction before investing in other channels). Your development objective should be clear and limited in scope, something like: “I want my new product to do these three things at launch”. This will let you work backwards and define the rest of your plans.
What talent do I need in order to build my product?
One of the initial plans you’ll need to work out is the type of human resources you’d require to develop your product. Think about the different areas of your process, core-development, testing, integration, deployment, team management, and more. Getting the right talent on a short notice can be a huge challenge and may even derail your launch timeline (if not plan ahead).
You don’t need to hire everyone from day one though, especially on long-term projects, just need to apportion time for the hiring process. Alternatively, you can also outsource certain development tasks to freelancers or boutique development firms specializing in those areas. This brings us to a bigger topic:
What should I build in-house and what can I outsource?
You can’t make everything in house. The mobile industry is a good example of this. Most manufacturers source components (such as chipset, storage, etc.) from several companies and assemble them into an appealing product.
This has increasingly become relevant in the software industry. You can build your own SMS relay infrastructure, for example, or integrate with a ready-to-use messaging platform and simplify your development process.
It can be tough to decide what and how much to build in-house versus what to outsource. But here are a few factors that you can consider:
- How sensitive is your data being handled by this component?
- What is the cost of development vs. acquisition? If a recurring cost is involved, what lifetime cost you can expect?
- How much of a disruptions in service would occur if the service provider of that component is facing an outage?
- What support would you need when you scale your operations?
- Is the effort to develop a component in-house worth it over the long-run, considering that technology my need upgrading to stay competitive?
On a related note, the last questions brings up an important point, we shall explore next:
How long will my chosen technology carry me into the future?
You should not be hung up on a technology. Your choices today can turn obsolete in a few years (as has happened many times in the past). Likewise, some of the programming languages used today weren’t available a mere decade ago.
Rewriting an entire codebase is not unheard of but extremely complex and time consuming. This is why choosing a technology that will support you for the next several years is essential.
Think about your feature roadmap; can the technology support your pipeline? Alternatively, can it integrate with tool that can?
Also think about compatibility. What platforms of distribution you need to support? Can you reuse components or frameworks to minimize development efforts. For example, with recent advancements in web technologies, frameworks such as Ionic have become a viable option for combined product development.
How scalable is my infrastructure?
Last but not least, scale is a critical variable to consider. The general trend is to move towards cloud computing. In fact, many apps function on a cloud-based backend today, having only limited functions processed locally.
Even if you start with a small user base, you must consider your long-term future as well. While most modern cloud platform providers (such as Amazon and Microsoft) have built in processing plug-ins and storage space that are designed for scalability, your development itself needs to be scalable too. That means not designing bottlenecks into your release process or having a system that is not scalable itself (such as a traditional database, or inefficient API designs, or even poorly apportioned cloud infrastructure).
In the end, however brilliant your idea or design may be, it is the underlying technology that will carry it towards success in the long-run.
This article was written from the perspective of company management, who are generally non-technical in background, and it reflects in the choice of words and details included. If you want to know more about the process of development itself, I highly recommend you read the blog by TechBeacon on selecting the right development tools.
Thanks for reading! I’d love to know your thoughts in the comments.
This article is a part of the series Getting Started with a New Product, where I address five crucial questions every product creator should ask before starting on a new product journey:
1. How do I know if my idea is good?
2. What is the best way to monetize this product?
3. Am I implementing the right technology? (What You Read)
4. Is now the right time for this product? (Up Next)
5. What kind of marketing do I need?
You can also read the series summary here.
Follow me on LinkedIn.
