How to build great software products?

In what way do you need to shape your company in order to deliver valuable products to your customers? This is a question I am dealing with since I was involved in the process of software development almost 10 years ago. From my perspective as product owner and web developer, I believe great products are the outcome of an inspiring culture, honest communication, and solid code integration.

1. Inspiring culture

It is simple, an unmotivated team leads to bad products. As a team lead you better make sure that you know your team: What motivates them? What are their career goals? What can you do, to put your team into an environment that motivates and triggers the personal best? In the end, humans are diverse, make sure you have an individual approach to anybody. However, as a role model you can set the tone.

Provide an explicit direction

In other words: Why are we here anyway? A common idea about the product among the entire team is like a compass on an expedition. It demonstrates the direction and reduces the chances of investing time in features that add low, or even worse, no value. Moreover, if you set the direction you give your team a chance to identify with the goal. At that point, it becomes interesting in terms of motivation.

As an example, the delivery startup Gorilla is doing that very well, because they succeed in setting the direction in a simple and clear way: "Groceries delivered in 10 minutes". Proton, the online security company claims: "We are building an internet that protects privacy." Those examples set the direction, it is an offer for people to join on that mission. A shared goal among the employees is a great basis to build upon. Of course, such a goal is quickly formulated, acting accordingly is the key to sustain the momentum.

Support, trust and feedback

The relationship among the development team and their product owner is crucial for success in product development. It is a mutual dependency. Whereas the product owner defines the task in line with stakeholders interests and a strategic product vision. The development team is responsible for the implementation. The transformation of a concept into a product.

In order to maintain successful product development, everybody needs to understand that they only succeed as a team. A great concept alone is worthless. Similarly, a great execution of a bad concept, doesn't make the product any better. Being a great team starts with a discussions on equal basis: How do we need to work with each other to establish a culture of support, trust, and honest feedback?

It is a promising sign, if you succeed as a team to define the way you want to work. Whether this is more micro or macro managed, underlined by ultra-agile or only somewhat agile methodologies is secondary and depends on the peoples background (level of seniority, cultural dimensions). Make sure to test your process, evaluate regularly and honestly and don't be afraid to adjust along the way as needed.

2. Discovery sessions

A certain way that leads far away from building great products are misunderstandings. You can't avoid misunderstandings all the way as they are part of human communication. However, if you pay great attention to key conversations along a product life cycle (during development and after launch) the likelihood of building something great increases. 

Most important, leverage on a face-to-face conversation as often as possible, that also works remote with a simple video call. Not using face-to-face conversations is far more expensive in terms of time and money burned than you may image. In addition, direct communication belongs to one of the 12 agile principles as stated in the agile manifesto: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." 

Understand the user's context 

Eventually, you build the product for a certain user base. Make sure to have a strong connection to them, understand their roles, understand why and how they interact with your product. However, never take a feature request for granted. Instead, invest time to understand the root cause that motivated a customer to request a certain feature.

Recently a user asked me, whether we could provide an export feature for certain documents. Of course that would have been possible, however I was keen to understand in what context he wants to use this feature. The answer was interesting: The user wanted to download those documents from the application to share them with colleagues by email.

As soon as I guided the user to our already existing document sharing feature within the application, the customers request was solved. In addition, I learned that we may need to improve the awareness of our sharing functionality to our user base. An important insight, you may only gain when you engage with your users.

Engaging with your users in combination with conducting user analytics can even be more powerful. This way, you may get quantitative data that demonstrate how user interact with your app. Engage with them afterwards to understand why they interact in a particular way. 

Brainstorm solutions with your team

The discovery phase is a vital process in product development. Once you take this serious your chances of transforming an idea into a valuable product (or feature) - a feature that solves a real business problem - rises significantly. It involves three steps:

First, talk to your user(s) and make sure you understand their problem (mind the user's context!).

Second, with your entire product team (at least with representatives of each discipline like a developer, designer, tester) start a discussion about the user's business problem and brainstorm solutions. If your team can spend those discovery sessions in a motivated and creative way it will most certainly be the base for a valuable product development.

Check the solutions you come up with against possible risks. Usually you'll face three kind of risks:

• value risk: is it worth to invest the needed resources to make this solution work?
• validation risk: will this product certainly solve the users problem? And can the user handle the tool?
• feasability risk: are we able to build and integrate it? 

Finally, document the requirements from a users perspective. Start with "As a user, I want that X happens when a click on Y". In addition, take into account that visualizations are worth more than 1000 words. Screenshots and rough outlines have great power when it comes to documentation.

Also, differentiate among business and technical requirements. Whereas "select a data cryptography method for above standard encryption security and quick decryption process" is a business requirement and "secure data with elliptic curve cryptography" is a technical one. Use technical requirements only, when you know what you are talking about and when it is a strict requirement from your stakeholder. In any other way, empower your development team for finding the right technical solutions for the business requirements.

Before you ship the feature to your client ensure that it meets the defined requirements. Therefore, you need to have an idea of how to test the acceptance for each defined requirement. Moreover, be aware of side effects. The bigger your product becomes, the more complex a rigorous quality assurance gets. Invest into automated testing concepts.

3. Code integration

A new product isn't done until it is out in the market and available to (a segment of) your customers. How to push your products from a development environment to production? This is a very important question that determines the frequency and quality of your product updates.

Emphasis on TDD

Imagine a developer makes a PR for a new feature branch. This enfolds the following process:

1. A new app is build and validated against the automated unit and feature tests. Once the new code is successfully validated it will be continuously integrated into the main branch.
2. The new code base is continuously delivered to a staging server that mimics the production environment. Again, the code is validated against your test suite. In addition, manual (UX) tests can be performed.
3. Once the new code base is successfully validated on staging you can manually trigger the automated deploy to production process.

Build CI/CD processes 

Such a CI/CD process only works if the development team puts a strong emphasis on test driven development (TDD). Once the test coverage is strong and complete, even the deployment process to production can be fully automated.

Such a TDD approach may reduce your development speed initially, but in the long run everybody benefits: Your team feels comfortable about the product because it is well tested. New features go live in minutes. Customer feedback comes quickly.