How to Build a Software Feature Faster? A Guide for Product Managers
In ambitious tech companies, there is always a demand to build and ship products and features faster. For most features, I would argue that a product manager (while always having a definite sense of urgency) needs to lean more towards excellence in the outcome rather than adherence to the planned timelines. But, there are some scenarios where timelines become truly “sacrosanct”. Let’s briefly discuss these scenarios.
When to build faster?
1. Customer commitments made
This is common in enterprise B2B products where a customer has agreed to buy a software after getting a firm commitment from the software provider during the sales process to add certain additional capabilities to the system. This commitment might be part of the signed contract as well.
2. Public events or external announcements done already
Product launch dates are sometimes announced in advance. Customer and press events need to be planned well and the dates cannot be moved around without impacting the brand. Companies also plan to show product demonstrations in events like the CES which can help create a buzz.
3. Regulatory requirement
For a company to continue operating within the law, they will need to meet any new legal or regulatory need within the deadlines provided by the authorities. While this is very much the case in fintech, it is fairly common in e-commerce, mobility, telecom and health-tech as well. Further, consumer data protection and data localization laws can impact pretty much all tech companies.
As an aside, a very successful product that I have observed personally was an offering we launched when I was at IVP that helped hedge funds easily perform Form PF filings. This filing was a regulatory requirement imposed on asset managers as part of the Dodd-Frank Act with a strict timeline for the first filing and quarterly filings further on. By launching the solution at the right time, a good chunk of the market could be captured by IVP. The company was later able to deepen the offering to create a full suite of solutions for addressing all other reporting needs, but none of that would have been possible without the initial hustling by the team to get the first version out in a couple of weeks.
4. Time-bound market need
Imagine you are part of an e-commerce product team. You want to launch some capabilities in your app that will help merchandize and discover deals better. Or you want to add dynamic discounting or pricing capabilities based on real-time demand. And you want to do these changes before a Diwali sale window comes up. You would better find a way to ensure that the capabilities are fully ready on time as the opportunity cost of missing the sale season will be way too high.
5. Internal feature
In an earlier post, we had talked about how a big part of the product work in large organizations is in building internal products. While internal products have their own challenges, a key advantage is that they are more amenable to iterative features with quicker feedback cycles and ability to influence the internal users to follow specific usage workflows. In such products, it makes sense to prioritize speed over perfection.
How to build faster?
So, when there are good reasons to ensure shipping a feature by a target date for sure, what can a product manager do to ensure it happens? What tradeoffs might need to be made?
Btw, if you are wondering why a product manager (rather than a program manager or engineering manager) needs to care about meeting the target date, you might find this post useful.
1. Reassess the scope of the problem
The first step is to thoroughly understand and identify what’s the minimum version of the feature that’s needed by the launch date and see if the overall capability can be phased out. It involves asking questions like:
- Are all the use cases relevant on day zero? Are we sure we are not solving for any imagined needs?
- How will the user experience be impacted by reducing the scope?
- What’s the cost of delaying some parts of the problem to be solved later?
- Is there an operations side to the problem? If yes, is there really a need for a user interface for the internal ops teams to start with or can they make do with a spreadsheet-driven process?
2. Reassess the nature of the solution
Once the problem is probed sufficiently, the next step is to similarly analyze the proposed solution to decide how it can be built quickly. This involves asking more questions:
- Do we necessarily need to build the solution in-house? Would buying and integrating make more sense — short-term and long-term?
- Is there some long forgotten thing built elsewhere in the organization that solves a similar problem? Can that be leveraged here with some changes?
- Is there really a need for configurability at launch?
- Can we consider building a PWA instead of a native solution?
Another aside: PWAs have become pretty powerful these days. Check out this site from where you can install a PWA app that showcases all the capabilities such apps have now — ranging from media capture to device authentication to Bluetooth and NFC.
3. Improve the planning
Once the problem and solution have been thoroughly analyzed, the execution planning should be put under the microscope.
- Identify possible risks upfront. Is there any unproven tech that’s planned to be used? Is that really needed and if so, how can that be validated quickly? Are there any integrations between systems and particularly with any external systems involved?
- What are the granular streams of work? Are those independent and so can go in parallel? What are the dependencies between the streams?
- Will the feature need legal review? Does it need a security review? Can those processes get started without the feature needing to be fully ready?
- Should we have our “A team” working on this? How can we realign other work to do this?
4. Improve the execution
When your feature is in the weeds of development with a deadline looming, what can you do as a PM?
- Get to know your engineers and work with them directly. Do not be dependent on engineering managers or program managers. Establishing a direct line of communication with the folks doing the coding reduces unnecessary overhead and allows faster clarifications to questions that will always come up in the middle of development.
- Track the progress daily and identify slippages. Work with the team to see how gaps can be closed before they become bigger.
- Keep taking demos from the engineers to understand exactly where things stand and provide early feedback. It’s fine if backend and frontend systems are not integrated in these demos or if the data used is dummy.
- Do not just leave the testing to the QA team. Use the feature yourself and guide the QA team and help them prioritize their more rigorous testing efforts. A PM with good intuition about the customer and product can usually uncover a surprising number of issues in quick time. Also, get other PMs to use the system and get their feedback.
5. Work longer and harder
When everything else that we have discussed so far is exhausted but achieving the target date still looks tough, get ready to grind it harder. As a PM, you will need to personally set an example if you expect your engineering team to work longer or work weekends. You will need to be available — to clarify, unblock, test and more importantly to ensure that everyone feels they are into it as a team. Work with the HR team or program folks to ensure the team is provided food in the office and flexible transport facilities. Celebrate even the smaller milestones like launching a pilot.
Happy sprinting!
