Product Development Roadmap – Insights, By A Developer, Into The Process Of Developing New Products From The Bare Bones
I am Shivang, a software developer by profession, the author of this write-up as well as the founder of this blog. In my past life, I worked as a full-stack developer with the Hewlett Packard Enterprise Technical Solutions R&D team. You can read more about me here.
The whole purpose of writing this article is sharing the little knowledge I have, with the community, on developing a software product from the bare bones. These are the key things I wish I would have known when developing my first product.
In these years of development, I’ve written numerous projects from the ground up, spent countless hours scavenging the web, browsing through technologies, frameworks to pick the right tech that would align with my requirements. I have wasted days, if not months, trying to implement stuff with a not so fitting technology. I have implemented stuff with tech having no support and community and have later cried for days into a pillow.
Picking the right tech stack & well as moving ahead with the right architectural design is crucial for the success of our product. There is no way around it. I think we all understand this fact pretty well. Once we pick the tech & get down to coding there should be no looking back. We naturally can’t afford it.
Let’s step by step go through different phases of developing a software product, a startup, a project or whatever you want to call it.
This is the most important part of the whole journey and shouldn’t be taken lightly. Before you even think of starting with the application design or picking the technology stack or anything, you should be thorough with your market research.
You should be crystal clear on things like why would a customer use your product as opposed to using your competitors’? What are your USPs?
What platform would suit best to launch your product? Mobile? Desktop? AR VR? Where do your target customers hang out & stuff?
Considering the existing competition, if there is any, how fast would you need to scale? What strategies do you have to out-market them? What additional/unique features should your product be loaded with to outclass every existing solution in the market?
I am not going to talk much about this. You are a smart bunch of people and I know you got the point.
There are a plethora of interesting articles already written on this. Just run a search on google for “market research for startups”
Here are some of them that I recommend reading:
Are You Certain You Need A Mobile App For Your Business? – This is written by me and is another post on this blog.
Think With Google is a pretty nice website that I came across to get the latest market insights from Google.
Moving on, let’s talk about the importance of having the architecture of our application right.
Importance Of Getting The Application Architecture Right
The key element in successfully creating anything is getting the base right. Now whether it is constructing a building or making a pizza. If we don’t get the base right, we have to start over. Yeah!!… I know, but there is no other way around.
Building a software product is no different. The architecture is it’s base & has to be carefully thought, to avoid any major design changes & code refactoring at a later point in time.
Speaking with experience, you don’t want to delve into re-designing stuff. It eats up your time like a black hole. It has the potential to push your shipping date further down the calendar by months, if not longer. And I won’t even bring up the wastage of engineering & financial resources which is caused due to this. No, I won’t!!
It also depends on what stage of the development process we hit an impasse due to the hasty decisions taken during the initial design phases. So, before we even touch the code & get our hands dirty, we have to make the underlying architecture right.
A look at the architecture of our app should bring a smile to everyone’s face.
Though software development is an iterative and evolutionary process, we don’t always get things perfect at the first go. Still, this can’t be an excuse for not doing our homework well.
An Overview Of The Product/Software Development Process
In the industry, architects, developers and product owners spend a lot of time studying & discussing business requirements. In software engineering jargon, this is known as the Requirement Gathering & Analysis.
Once we are done with the business requirements, we sit down & brainstorm the use cases which we have to implement. This involves figuring out the corner cases as early as possible & fitting the Lego blocks together.
If you’re a fan of documentation, you might also want to write a high-level design document.
Now, we have an understanding of the business requirements, use cases, corner cases and all. It’s time to start the research on picking the right technology stack to implement the use cases. I’ll talk about this further down this article.
Proof Of Concept
After we pick the fitting tech stack, we start writing a POC (Proof of Concept)
Why a POC?
A POC helps us get a closer, more hands-on view of the technology & the basic use case implementation. We get an insight into the pros and cons of the tech, performance or other technical limitations if any.
It helps with the learning curve if we’re working with completely new tech, also the non-technical people like the product owners, stakeholders have something concrete to play with & to base their further decisions on.
Now, this is only for an industry scale product. If you are a solo indie developer or a small team, you can always skip the POC part and start with the main code.
So, we showcase the POC to the stakeholders & if everyone is satisfied, we finally get down to creating the main repo & our first dev branch on GitHub, or any other similar code hosting service which you prefer.
So, by now you would have realized how important it is to get the architecture right at the first time & the knowledge of web architecture to product developers.
A part of the content in this article is taken from my web application and software architecture 101 course. If you have a startup idea & you are asking yourself, how do I implement my app? What technologies do I use? Where do I start? This course will help you kickstart your entrepreneurial journey. You can read more about the course here.
Picking The Right Tech
Be Thorough with Your Use Case & The Requirements
We should be crystal clear on what we are going to build. Things should not be hazy. We cannot pick the right tech if we are unclear on the requirements. Once we go hunting, we should be clear on what we are looking for.
For instance, when looking for a database, we should be clear on if we are going to store relational data or will it be document-oriented, semi-structured or with no structure at all.
Are we handling quite a large amount of data which is expected to grow exponentially? Or the data is expected to grow at a manageable pace upto a certain limit?
Will a monolithic architecture serve our requirements well or do we need to split our app into several different modules?
Splitting the app into several modules, using heterogeneous tech in services, helps us bail out on a particular technology in case things don’t work out.
See If What We Already Know Fits the Requirements
It’s easier to build new applications with the tech we already know. We don’t have to go through the steep learning curve that comes along with the new tech.
Also, things are comparatively clearer when using the tech, we are well familiar with. Being aware of the nitty-gritty, having familiarity with the errors, exceptions & the knowledge to fix them helps us release the features at a quick pace.
Avoid running for shiny new toys until you really need them. Do not fall for the hype.
Imagine an exception thrown by a new tech which you haven’t seen before ever in your life & also cannot find the solution online. You are stranded. There is no one to help you, all you hear is crickets.
I’ve been there, done that. It’s frustrating, clicking through all the search result pages of Google. Finding nothing.
Does the Tech We Have Picked Has An Active Community? How Is the Documentation & the Support?
The technology we pick ought to have an active community. Check the involvement of the community on portals like GitHub, StackOverflow etc. The documentation should be smooth, easy to comprehend.
Larger the community, the better. Having an active community means updated tools, libraries, frameworks & stuff.
See if there is official support available for the tech? There should be some rescue available if we get stranded down the road. Right?
Is the Tech Being Used by Big Guns in Production?
If the tech we are picking is being used by big guns in the industry, then this confirms it being battle-tested. It can be used in production without any worries.
We can be certain that down the line we won’t face any inherent scalability, security or any other design-related issues with the technology. Since, the codebase is continually patched with new updates, bug & design fixes.
We can go through the engineering blogs of the companies to get more information on how they have implemented the tech.
Check the License. Is It Open Source?
Picking an open-source technology helps us write our own custom features in case the original solution does not have it. We do not have to rely on the creator of the tech for new features & stuff.
Also, in terms of money, we don’t have to pay anyone any sort of fee to use the product. Open-source tech also has a larger community since the code is open to all, anyone can fork it, start writing new features or fix the existing known bugs.
Availability Of Skilled Resources on the Tech
Once our business starts gaining traction. We would need a hand to move at a quick pace & roll out new features within a stipulated time. It’s important that there are enough skilled resources available in the industry on the technology we pick.
For instance, it’s always easy to find a MySQL administrator or a Java developer as opposed to looking for a resource skilled on comparatively newer technology.
Now, fellas!! is the time to start writing code 😊
Building An MVP
Storming The Market With The First Version Of Our Product – Writing An MVP (Minimum Viable Product)
When writing an MVP, be brutal about cutting out features. Throw out all the “good to have” features, get the skeleton ready, write the bare minimum necessary features first. Having the skeleton ready, something you could show it to your team and friends won’t just brim you up with energy and motivation but will also enable you to launch your MVP before the deadline.
I know you would love to have all the beautiful features you have in your mind in the first release but please don’t get sucked up in that black hole. Always have a timeline in mind, live and die by it. Motivation and resources are limited.
Treat yourself as on a Navy SEAL mission, you have to get in there, do your thing and get out.
When you have an MVP ready, show it to the community. Get feedback. Reddit and IndieHackers are beautiful places for starting a discussion. You can also start a crowdfunding campaign for your product on Kickstarter or somewhere. If it’s an open-source thing check out OpenCollective
Seeking Out Help!!
For any kind of help related to code, there isn’t a better place than StackOverflow
Dev.to is an amazing portal for starting discussions with respect to building software.
If you are stuck with software design related issues join this software architecture subreddit.
Here is my LinkedIn profile in case you want to say Hi!! 🙂
I’ll see you in the next writeup.
More On The Blog
- Distributed Systems & Scalability #1 – Heroku Client Rate Throttling
- Zero to Software/Application Architect – Learning Track
- Java Full Stack Developer – The Complete Roadmap – Part 2 – Let’s Talk
- Java Full Stack Developer – The Complete Roadmap – Part 1 – Let’s Talk
- Best Handpicked Resources To Learn Software Architecture, Distributed Systems & System Design