Guidelines for Building Software Products

I founded a software company straight out of my university days. The product has received good traction and scale. I have made a lot of mistakes and learned a lot on management, technology and how to build good product dev teams.

The following are collated general guidelines for teams:

Understand the problem deeply. The first key requirement is understanding in depth the problem(s) you are solving. Start with one key problem, solve it really well and only then move on to solving the next problem. Customers have many problems, and as a startup you can’t work on too many things at once. Splits focus. Do less but do it extremely well.
Make the environment fun. A very significant part of our waking hours are spent at work. For our teams, we must make the environment fun. It’s always more engaging to work while having fun versus not - else you’re looking at the clock to turn 5 PM.
Be picky about team and culture. A group of good developers, product managers and designers who are able to work well together is a definite must. Be very picky about team choices and culture - and do not compromise.
Promote accountability through autonomy. Give full responsibility to a small integrated team of designers and developers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. This is completely different from other methodologies, where managers chop up the work and developers act like ticket-takers. When teams are more autonomous, senior people can spend less time managing them.
Adapt methodologies to your team. Rigid methodologies, even timelines sometimes tend to fail and there should be room for adjustment. People, teams, requirements, and environments are infinitely different and dynamic. A methodology unique to an environment and a team has to be modelled, in the same vein as “right tool for the right job”.
Empower leadership. A leader must be empowered to shape the organization as much as the product roadmap is shaped. A method-less / leader-less organization won’t have the right culture, processes and working style.
Start from user journeys. All features should follow a use-case from users. At the first level, it should be rough, solved and bounded on a piece of paper. The shaped concept is an interaction design viewed from the user’s perspective. It defines what the feature does, how it works, and where it fits into existing flows. Create a user journey, then a PRD with final wireframes, then review the PRD. Once everyone signs off, roll out into development. It is important to not do changes once the development is complete as that results in exponential technical debt unless that change has been planned for.
Right tool for the right job. Tech stacks should follow “right tool for the right job”. Every choice made in adopting a technology has serious long term ramifications.
Keep the stack simple. Keep the code and stack as non-fancy and simple as possible. Heavy on common sense and light on coolness.
Let technical people make technical decisions. A tech team should be run with a developer-centric approach, and not a business or management-centric one. Technical decisions, even the ones with business implications, should be made by technical people. Otherwise, in comes the feature-creep, bloat, technical debt, and burnouts.
Have a vision. The best software has a vision. The best software takes sides. When someone uses software, they’re not just looking for features, they’re looking for an approach. They’re looking for a vision. Decide what your vision is, what your positioning is and run with it. Don’t create something for everyone - that way you become nothing for no one.
Do less. Stick to what’s truly essential. Good ideas can be tabled. Take whatever you think your product should be and cut it in half. Pare features down until you’re left with only the most essential ones. Then do it again.
Manage technical debt actively. Be extremely wary of technical debt. Know when to scrap and rewrite systems. We have scrapped and rewritten the majority of our stack multiple times, improving them significantly with each iteration. These are tough decisions; extremely important trade-offs.
Always experiment. Always experiment, brainstorm and do more things.
Communication over charts. Project management isn’t about charts, graphs, reports and statistics - it’s about communication. It also isn’t about a project manager sitting up high and broadcasting a project plan. It’s about everyone taking responsibility together to make the project work. But we also need someone to keep the bus on track.
Build cross-functional relationships. Build organic, meaningful relationships with non-tech teams within the organisation. Work with small non-tech teams within the organisation (subsets of support and sales) to critique and validate products, gather feedback and data, and to do QA. Encourage natural cross functional relationships.
Be particular about quality. Be extremely particular about quality and consistency. That extra 50 KB of Javascript, or that 100 KB PNG on a web app, or that sudden 10ms spike in mean latency, are not acceptable. No matter how negligible the cost may be, it is a matter of principle of good engineering.
Design matters. Good design is paramount. Building software for humans with no consideration for human interactions and sensibilities is criminal. Keep UIs and interactions simple, typography crisp, clutter minimal, and spacing calm.
Optimize costs. Consider technology costs as engineering challenges. Always optimise where possible and don’t spend what is not absolutely necessary. Frugality and moderation should be second nature.
Don’t fear feature-freezes. Don’t be afraid to do feature-freezes to build tech the better way. It is okay to slow down to build cleanly, as what is built now will have serious implications in the future. The technical leaders should take the decision on this - not business folk.
Trust people. Trust people and tolerate (even terrible) mistakes. The key is in learning by trial and error and not repeating the same mistakes. Not everyone is a 10x hotshot ninja, and that is okay. Everybody has their own critical role to play. Be patient and let talent grow.
Have fun. Having fun is extremely important. If there is an opportunity to make things fun, irrespective of how “serious” the status quo of an environment is, things should just be made fun.