Minimum Standards of Product Development

Fostering collaboration and continuous innovation

At NewStore, we take pride in our commitment to advancing retail technology, constantly striving for excellence in our Product and Engineering efforts.

However, the path toward innovation is not without its challenges, especially concerning collaboration across different teams. Recognising the need for a harmonised approach to work together as #oneteam, we embarked on a journey to redefine our Product and Engineering development processes, setting a new standard for collaboration and efficiency.

As a starting point, every Product and Engineering team shares a common understanding of what excellence looks like and speaks the same language regarding the day-to-day steps of developing a software product. To facilitate this, we organised our Minimum Standards of Product Development around the following set of seven core principles, providing clear guidance and examples of what to expect in each.

1 - Understanding Your Market and Customers

🤔 Approach: Start by understanding your customers’ needs. Conduct market research, interviews, and surveys to identify the problems your product will solve. Do this continuously, not just at the beginning of a project or initiative. Be prepared to pivot or make changes based on the feedback you receive.

🥅 Outcome: A clear definition of your customer personas and their needs, resulting in a product that truly meets market demands.

👍 Cool behaviours: 

• Solve problems based on customer feedback and market research.

• Continuously gather customer feedback through interviews, store visits (particularly relevant for our work with retailers), and surveys.

• Adapt priorities based on customer feedback.

• Collect feedback from at least 4-5 customers per problem space to ensure adequate market coverage.

👎 Uncool behaviours:

• Make assumptions about what customers need without verification.

• Get customer feedback only once at the beginning of a project and never revisit it.

• Assume we know what the customer wants without seeking confirmation. 

• Continue on the same path despite feedback showing it isn’t working (sunk-cost fallacy).

• Rely on feedback from a single customer or avoid talking to customers altogether.

2 - Empowerment through Ownership

🤔 Approach: Teams take ownership of their parts of the product, adhering to essential standards of product development and fostering a culture of accountability and innovation. Embrace the mindset: You build it, you own it, you run it.

🥅 Outcome: Our Product and Engineering teams not only create and develop solutions but also take full ownership and responsibility for them.From inception to deployment, documentation, and ongoing maintenance, team members drive the initiatives, ensuring consistency, quality, and a deep understanding of every aspect of their work.

👍 Cool behaviours: 

• Team members are invited and encouraged to actively engage in customer calls, with a preference for a healthy rotation rather than everyone participating simultaneously.

• Teams own their 24/7 operations, including the on-call process, monitoring and alarms.

• Stream-aligned teams take ownership of their domain in the backoffice, mobile apps, own their deployment pipelines and their documentation.

• The team collectively decides on priorities, rather than the Product Manager or someone outside of the team.

• Stream-aligned teams are composed of full-stack engineers and generalists, rather than specialists in specific technologies.

👎 Uncool behaviours:

• A team member not participating in customer calls for months.

• Depending on another team to handle on-call duties for your domain. 

• Expecting the SRE team to solely own and define deployment pipelines for all teams.

• Having one engineer exclusively responsible for a single part of the codebase.

• Having one engineer handle QA or deployment tasks for the entire team.

• Splitting the team, with one part focusing on backend development and other on frontend.

• Dividing the team, with one part focusing solely on infrastructure while the other handles the rest.

3 - Iterative Development

🤔 Approach: While developing market-centric solutions, utilize short, iterative development cycles lasting no longer than 1 to 4 weeks. This ensures swift availability of running software in production, facilitating frequent feedback and continuous improvement.

🥅 Outcome: A product that adapts to users’ feedback and evolving market needs.

👍 Cool behaviours: 

• Generate ideas for the problems or needs you’re addressing.

• Get feedback for each iteration in a controlled environment with a small subset of users.

• Deploy updates frequently in smaller batches.

👎 Uncool behaviours: 

• Brainstorming solutions for potential customer problems that may not yet be evident.

• Introducing unnecessary complexity to solve potential future problems.

• Waiting until the end of several months in the development cycle to seek feedback and validate assumptions with real users in production.

4 - Test-Driven Development (TDD)

🤔 Approach: Default to following the red-green-refactor steps of Test Driven Development.

🥅 Outcome: Each new functionality is thoroughly tested and fully functional upon implementation. The modular nature of new functionalities reduces the likelihood of bugs.

👍 Cool behaviours: 

• Test as implementation progresses.

• Let the TDD red-green-refactor to guide architecture design decisions.

• Embrace refactoring and code removal.

👎 Uncool behaviours: 

• Test after writing the code.

• Design solutions without considering tests.

• Rely solely on AI tools to generate tests for created code.

5 - Pair Programming

🤔 Approach: We suggest that teams default to pair programming.

🥅 Outcome: Code quality improves, facilitating easier knowledge sharing within the team and reducing knowledge silos.

👍 Cool behaviours: 

• Engineers default to pairing or mob programming.

• Product Managers and Designers join pairing sessions as necessary.

• The team collectively owns the code.

👎 Uncool behaviours: 

• Engineers default to working in isolation.

• Product Managers and Designers don’t participate in pairing sessions to help Engineers.

• Specific Engineers are assigned ownership of certain parts of the code.

6 - Continuous Integration and Delivery

🤔 Approach: Integrate and deploy changes frequently to production, ideally multiple times per day. This minimizes code integration issues, enables rapid adjustments, and enforces rigorous quality testing to ensure fearless deployment.

🥅 Outcome: A stable, up-to-date product that is always deployable.

👍 Cool behaviours: 

• Implement independent pipelines per service.

• Automate deployment to production, eliminating manual intervention. 

• Ensure automated tests run in the pipelines, with trust in their ability to guarantee quality.

• Adopt trunk-based development.

👎 Uncool behaviours: 

• Utilizing a single pipeline for deploying multiple services.

• Maintaining long-lived Git branches (one per environment, for example).

• Relying on manual clicks to deploy to production.

• Deployment pipelines taking over 20 minutes to run.

7 - Regular Reflection and Adaptation

🤔 Approach: Regularly reflect on processes and practices, adjusting as needed to enhance efficiency and effectiveness.

🥅 Outcome: A development process and team that continuously improve.

👍 Cool behaviours: 

• Create regular opportunities to question processes and practices, such as retrospective and post-mortems.

• Adapt processes and practices as needed on an ongoing basis.

• Adjust priorities and areas of focus whenever necessary.

👎 Uncool behaviours: 

• Ignoring best practices or processes because they “don’t work for you.”

• Refusing to entertain questions about practices or processes with the rationale that “this is how it’s done.”

• Persisting with the same focus during a sprint or iteration even when it’s apparent that it’s incorrect.

• Only questioning priorities once a quarter, despite realizing during the quarter that current activities may not be the most crucial.

• Failing to seek help when encountering obstacles.

Conclusion

We are still in the early stages of defining these standards, but we’ve already noticed reduced friction in collaboration between teams on cross-functional topics and increased knowledge sharing among members across different teams.

Additionally, we’ve observed a decrease in knowledge silos within and between teams, leading to a stronger collective ownership of our product.

It’s important to remember that as we implement these standards, we’ll continue learning and evolving with each iteration.