A philosophy of software product development

This post is an attempt to summarize what I have learned of product development during my seven years building software products in the industry. Please let me know what you think and what is missing!

Keep yourself educated

Building successful products is hard. Really hard. Most products fail. That's what makes product development so interesting.

Embrace the huge amount of knowledge on product development available in books and in the internet. Study that knowledge and learn from the mistakes others have made before you. Allocate regular time for studying product development. Share your learnings with others, and when someone shares their knowledge with you, respect the knowledge and thank them for sharing.

Pick a methodology and stick to it

Surprisingly many of us seem to just "wing it" when it comes to product development. We think our unique life and work experiences make us more likely to succeed than all those companies that failed before us.

To avoid this trap, pick an existing well established methodology and tailor it to your needs. Write down your product development methodology. Have everyone in the team read the book or watch the speech that explains your methodology. Examples could include The Lean Startup, Continuous Discovery Habits, or any of Gabrielle Benefield's videos. Iterate on and improve your process continuously.

Stick to your methodology of choice. When things start to look bad, it's very common for confirmation bias to take over. When this happens, we start to ignore negative feedback and keep pushing blindly forward. We hope that adding one more feature will lead to our users eventually seeing the light and start loving our product.

It is important to have faith in your vision and to persevere. But it's also important to know when to stop pushing forward and when to search for new direction. Having a good process saves a lot of time and money you would otherwise spend on building bad products.

Focus on the user

Focus on the user and all else will follow. The success or failure of your product is determined by the value you create to your users.

Teams often seem to focus on everything else other than their users. They spend time on crafting elaborate growth strategies, building quarterly development roadmaps, filling backlogs to ensure there's enough work for everyone, etc. These can all be important, but they're secondary to serving users. If the team fails to secure long-term trust relationships with users who find the product useful, usable, enjoyable and equitable, everything else will be in vain.

Establish a great customer support. Reflect on the feedback you get from your users. Always be thinking how you could create more value to your users.

It should be an exception to ignore user feedback. If you find yourself constantly ignoring user feedback, you're either working with the wrong users or you're blinded by confirmation bias.

Learn what makes good user UX and how to create products with good UX. See Google's UX Design course, Lean UX, _The Design of Everyday Things-, or Universal methods of Design. Everyone in the team should be familiar with such principles.

Establish a cross-functional core team

Engineers are trained to solve problems. Designers are trained to find the right problem to solve. Product-minded people are trained to capture business value in the market. All these viewpoints are needed to build successful products. If you have a core team of three engineers with a strong problem-solving focus, put extra emphasis on designing good UX and creating sustainable business value.

The cross-functional core team should work together every day. They should have ownership to iterate on the product as need. Do not force the team to stick to one pre-defined idea. Let them explore freely what creates most value to users.

Stay humble

You're building products to serve people. You help users solve problems and make life more enjoyable to them. If users do not like your product, you have either failed to create a compelling product or failed to communicate your vision to them. Anyway, the responsibility is on you. Do not blame the users when things go differently than you expect.

Think strategically

Building good products takes a lot of time. It matters a little where you are three months from now. It matters a lot where you are three years from now.

Find your beachhead. If you're building a product that is expected to capture value throughout the value chain, think how you could start small and expand from there. Try to integrate with the tools your users are already using.

Find the right early adopters. You may be planning to sell your product to Big Tech, but that doesn't mean they're the right early adopter for you. A good early adopter wants to work together with you. The better trust relationship you have with them, the better. In the early phase, you need regular and honest feedback. Such feedback can be difficult to get when working with companies much larger than your own.

Outcomes over outputs

It's important to focus on outcomes, not outputs. An outcome is a measurable change in human behavior that creates value, like "we increased customer acquisition to 20 users". Outputs such as "developed an iPhone app" are only useful because they drive outcomes like "increase mobile user acquisition to 100 monthly users".

Why outcomes over outputs? It is easy for the development team to deliver outputs like "iPhone app" without involving any users or creating any user or business value. Focusing on outcomes makes it much more likely that meaningful and positive impact is made to the world. Learning-based outcomes are easier to get started with than performance-based outcomes.

What do you think? Leave your comment below!