There’s always a tradeoff between time, money and quality in software development. More often that not nowadays, product managers are asked to deliver excellent products on a tight schedule and on a budget. Agile processes and the trendy idea of the minimum viable product only confuse things further because they seem to prioritise quick iterative development and a tight rein on features. How does one build a good product on time and keeping startup thriftiness in mind? I have six clear steps for you to follow:

One: Before building anything, dig to the roots and find product goals. Ask your client (or yourself) “Why do you need this product built?”. Answers like “We need to run a twitter campaign” or “We want a CRM for our sales team” are not clear enough. “We need to run a twitter campaign to promote our new startup” & “We need a CRM that tracks and updates senior managers about daily sales” are better answers, but ideally what you’ll dig for and get is the true reason behind the product’s existence. For the twitter campaign, it could be “reaching out to potential customers who are likely to purchase our startup’s product”. For the CRM, it could be “improving sales performance and making our sales team more accountable”. You are digging for goals—the why—not features—the what—that comes later, and that’s less important.

Two: Minimum viable product is a great idea. But when choosing what to whet down, keep the goals in mind. I have little patience for managers who come back and tell me, “But isn’t this what we decided to build?”. If you can’t deliver what your clients need, then you aren’t doing a good job. Keep product goals in mind, and prioritise features that will provide the most bang for the buck. Only then will Agile and MVP work well for you.

Three: Find great developers. What’s more important than your process are people. Great developers can manage themselves, figure out their own deadlines and do a lot more than a mediocre developer. Give them great tools too: a good working space, the editor that they want, and their operating system of choice. It’s also much better when you have a good team to split work into spheres of responsibility rather than into discrete chunks where many developers work on the same piece of code. Adopt practices like pair programming & SCRUM and promote discussion within the group. If at all possible, guide every discussion to a consensus and make sure every developer is aware of potential tradeoffs.

Four: Try as much as possible to not build engineering debt. This is easier said than done, but few rules go a long way: adopt a good source control system and practices, a development, staging and production deployment for every product, a continuous integration and deployment server, and have a system in place to code-review every commit before it gets merged back into the main tree. Make your developers police each other.

Five: Have an independent team to do security audits & quality assurance. This is a “manual testing” team, and while they might use several different tools, their mandate is to make sure the product has the features necessary, doesn’t have bugs, and is secure from a security standpoint. This team can be external to the company as well, but it needs to build a good rapport with the engineering division so that they don’t work at odds.

Six: Have regular deployments or sprints. Nothing focuses a developer more than a predictable schedule of deployment. Divide chunks of work into sprints and have staging deployments between them. Make sure that developers are responsible for successful deployments and pour woe to the person who breaks the build.

Well, those are the rules. Sticking to them is hard, and at times impossible, but my experience is that any deviation has always resulted in a loss of quality. While that might be acceptable in the short-term, in the long-term, it always comes to bite you on your ass. However, being a product manager is one of the best jobs out there! Figuring out the nitty gritty details of product construction, overcoming obstacles, finding consensus within the team and outside, and finally, building a product that meets the requirement is a very rewarding job. I’ve done a few stints here at MobME building good products and I’ve loved every challenge.