Welcome to the series How to build a tech product. This is article #5 of 11 articles that touch upon various aspects to consider while building a tech product.
In the previous post, we looked at how to choose a tech stack for your product, in this article let us look at how to go about estimating your product build.
Any tech product build will require a set of resources viz. developers, testers, designers and more. Project estimates are key to figure out how much time and in turn money will be required to build your product. When you reach this part of your product build you will need to start engaging with technical / design resources. These tech resources may be part of your team or part of a vendor team. Your motive should be to get an idea of the following aspects :
Type and number of resources needed
Effort estimates across each resource type
Costs associated with each resource type
Type of resources
| Resource type | Key Responsibilities |
| Designer | 1. Create brand guidelines 2. Product wireframes 3. Create the design and prototype Each of these deliverables need a review phase with key product stakeholders. Once you reach the design phase ensure that you get a prototype created using tools like Zeplin. This will help to ensure the design, UX and interactions that reach you development team have been wetted. |
| Product manager | Ensuring the key business and client concerns are incorporate into the product. Co-ordinating deliverables across all departments of the organization and ensuring on-time delivery. For a new product / startup, ideally, the product manager role should be played by one of the key internal stakeholders like a co-founder. |
| Architect | Bridging the gap between what needs to be built and how it should be built. For ex. choice of tech stack, break up product into components, component interactions, implementation of development best practices and more. The size and scope of your product will determine whether you will need a software architect. For a product that is starting just as a proof of concept, you could skip engaging with a software architect. |
| Developers | Code, perform unit testing and make sure the product meets the requirement 😃 |
| Testers | Ensure that the product is checked without any preconceptions from the dev team. Testers should be independent and focused on checking if the business requirements are met. |
| Internal users | Key stakeholders should set aside time for testing the product and also have feedback loops with the dev and test teams. For example, if you product has an impact on internal operations / support then your ops team should test the parts of the product that are relevant to their job function. |
To get a sense of costs and time, ensure you have estimates across all resource types
Effort estimations
Collate your effort estimations across the resource types that will be involved in building your product. Create a simple grid - example shown below. This grid should provide a view of your total effort estimate and thus time to market.
You can use a simple sheet like this as starting point for your high level effort estimates - download sheet
Add about 10-15% to your total estimate. This buffer will help in handling unforeseen delays and issues. Use these bumped up estimates in your business plans.
How to review dev estimates
As a non-technical product sponsor or key stakeholder reviewing technical / dev estimates can get overwhelming. Here are some pointers you can use to get a better understanding of your development estimates.
Get a work break down of dev estimates by module or component or screens.
Sort estimates in a descending order, then ensure that the estimates with higher values are most valuable to your business or the most complex parts of your product.
This process will also help in deprioritizing less valuable components to later phases.
Modules with similar size and complexity should have similar estimates.
If the team is using agile methodology for development understand which agile estimation technique was used and what were the base assumptions made while performing these estimations.
Add time for feedback and review in your development cycle. Ask for frequent touch points with key stakeholders to review development progress by looking at demos or playing around with the app. These early feedback cycles will help in getting things back on track in case the build goes off target during development.
Ensure there is enough time set aside for testing and live proving before the product is given to end users / clients.
Setting priorities
Estimations should provide a sense of how much time and capital is required to bring your product to life. Once you have your estimates it best to take a step back and prioritize your requirements. Verify if all the components being built are really required to prove your business goals. This is especially relevant if you are currently in a proof of concept mode. As builders we all love building things from scratch, resist that urge. Double check if everything you have decided to build is really required.
This would be right time to mark things as "nice to have" and move them to a later phase. You will be surprised how much of your product your users end up using. Build the minimum required to prove your business goals. Apply Paretos principle - 80/20 rule while deciding what really needs to be built.
Going tactical is ok!
There are times when your gut says you need a module, but there is a nagging feeling it might not be worth the time and effort. In such cases, go tactical - find a workable alternative which can be an off the shelf product which does nearly everything you need.
In some cases you can also substitute components with manual / offline human led processes where required. Once your product is live you will know if there is a lot of manual work coming your way. You can always build what you need when you reach that stage, backed by real world data.
Save dev efforts where possible, for example, use open source admin UI themes for your internal staff operations consoles.
When presented with a build vs buy choice. Go with the buy option, especially if the buy option is within budget. In the long run, you can always switch these components with self built or better options. Fight the urge to build everything you feel you need.
Remember everything you build needs to be maintained as well. At the outset, you should have your tech resources work on key business initiatives, instead of a nice to have internal CRM project which has no direct impact to your revenue.
Hope this article provides an overview of how to look at estimates while building a product. Please leave a comment if there are other aspects that you would like to see covered on this topic.
Next up, lets learn how to use these estimates to plan your project to execute your project.