Does your team keep learning?

At Qonto, we believe that our company’s success directly comes from our ability to grow people and develop their skills. Today, we’ll take a look at a tool we use and value: Standards.

Being a great Product Manager often comes with curiosity and passion for self-improvement. It also often means finding yourself in a torrent of books, articles, and podcasts, telling you about the best way to tackle this specific problem you and your team are facing. While experience helps you navigate between great advice and shiny artifacts, the risk of adopting a framework or methodology without making it yours is there.

A concrete example: how we write Product Specs

At Qonto, we’ve always been convinced that effective specs are critical in building a great product. They incite us to clearly organize our thoughts, pay attention to details, share information efficiently, and allow for a high-quality delivery with confidence.

As our team grew, we observed that every Product Manager had their own way of writing specs. Some PMs would provide as much context as possible to bring a sense of purpose to the team. Others would describe how the feature should be implemented meticulously to ease developers’ work, etc.

While they were all right, it became a source of friction between our tech and product teams. Over time, we realized we needed a common way to write product specs. I started looking for the perfect example, and, lucky me, the internet abounds with specs templates! I just had to pick what was best for us and build ours, which ended up looking like this:

1. Context
   - Problem
   - Current situation
   - Causes
   - Out of scope
   - Success
   - People and roles
2. Functional spec
   - User experience
   - Design guidelines
   - Tracking plan
3. Deliverables
   - Design
   - Copywriting
4. QA plan
5. Roll-out plan

This template looked comprehensive enough, and it only took a few days for all the PMs to adopt it. Shortly after, most of our specs related problems were gone. We had found a common way to write product specs that work and brought alignment between our tech and product teams.

The catch

A few months later, our initial problems got replaced with new ones. Our template had become too rigid. We started seeing specs with irrelevant pieces of information (“but the templates says it has to be there!”) or worse, missing ones (“but it’s not mentioned in the template!”). We had clear signals that something was wrong:

• Our team was following a process that didn’t work anymore without questioning it.
• Our team had stopped thinking about how to improve its way of working.
• We were not learning anymore, individually or as a team.

At this time, we could have decided to update our template to match our new requirements, but we decided it was time for us to define our standard for writing good specs.

Farewell processes, welcome Standards

The origin of work standards

The concept of work standards isn’t something new. It finds its origin in the industry, where it was developed as a tool to train personnel at scale.
During WW2, facing a massive shortfall of trained workforce, the United States Department of War launched the Training Within Industry (TWI) program. While relying heavily on work standards, the program allowed for 1.6 million workers to be trained in just 4 years.
After the war, TWI kept spreading across the world, especially in Japan, where it formed the basis of the Kaizen culture.

Without standards there can be no kaizen.
Taiichi Ohno

TWI defined work standards as a structured method for a given worker to complete a specific job. In that regard, each successful completion of a standard task confirms that:

1. The job is properly done.
2. The worker is well trained.
3. Work conditions are normal.

One interesting thing with standards is how they make it easy to detect and correct errors, mistakes, or delays, creating a fertile breeding ground for continuous improvement.

As previously mentioned on this blog in [Why is People Development our strategy?], the Qonto Way’s baseline is that our success is deeply tied to our ability to foster a learning environment where everyone can become better every day and be proud of their work. We logically got interested in the concept of work standards and worked to adapt it to a scaleup workplace like ours.

Standard, process, template, what’s the difference?

Here’s the common definition of a standard we use at Qonto:

A standard describes the best way to do a specific job, at a given time.

While the definition is broad, it means that unlike a process:

• A standard is owned and written by the team itself.
  The most capable people to write and update a standard are the people who actually use it in their everyday job. For instance, we have the deep conviction that having a PMs team reflect on the best way to conduct Product Discovery together is far more efficient than following their manager’s guidelines, no matter how great their expertise in the field is.
• A standard is constantly evolving.
  A process is usually a top-down initiative from a manager trying to bring stability to a team. In general, a process helps out the team until the situation has changed enough for it to become something bureaucratic. Remember our spec template?
  Conversely, standards are constantly challenged for improvement, as their maintainers are the people who use them in their everyday job.
• A standard doesn’t tell you what to do, but rather what you need to know to successfully complete the job.
  They help team members turn something difficult to achieve into something mechanical, so they can move on to learning how to tackle the next difficult thing.

Standards in practice

What a standard usually contains

As you can guess, there’s no template for standards. However, we learned that a good standard is generally a written document, rather short (between 1 and 2 pages), that captures:

• The intentions behind the job to accomplish: here, why we like to write detailed product specs and why it matters to us.
• The key factors in achieving good results: what we learned over time from successful examples
• The common traps to avoid: well… we don’t like to repeat our mistakes!
• And when it is relevant, what a good result looks like.
  Think of cookbooks. Some books (generally written for advanced cooks) will only describe the ingredients and steps to follow. Other books will also include a picture of the result. This picture not only provides guidance during the preparation but also helps assess how well you did in the end.

To illustrate, I’ve linked our current product spec standard below.

Read our Product Spec Standard

This standard captures all we’ve learned so far when it comes to writing a good product spec. It includes the lessons we learned by getting it wrong and will keep on evolving as we grow and learn.
Obligatory disclaimer: by the time you read this post, our standard will hopefully have changed!

A collective tool that serves individuals

Something exciting with standards is how they prove to be equally valuable for each team member as it is for the team itself.

At the team level, they gather and consolidate the knowledge and expertise the team has built over time while preventing us from occasionally reinventing the wheel. Working with standards forces the team to always think about how it can improve its way of working.

At a personal level, standards create a formidable opportunity for all individual contributors and managers:

As a PM, working with standards provides guidance and has helped me assess if I was doing a good job in various circumstances. It lowers the complexity of having to master a high number of tasks without turning me into a “template zombie.”

And as a manager, I regularly get requests for feedback or reviews from fellow Product Managers. Instead of reviewing and writing comments on my own, I suggest reading through the document together and compare it with the right standard. A well-crafted standard will help reveal specific aspects of their work that require improvement and will almost magically reveal the skills I can help them develop.

Things we learned on the way

While getting to work with standards proved to be remarkably effective, we identified several pitfalls to avoid:

• Do not aim for perfection and keep it simple.
  When we decide to write a new standard, we make sure to create a lenient standard. A standard must be realistic and easily applicable. If needed, it will eventually evolve, become more comprehensive and more accurate.
• Don’t try to standardize everything!
  If the problem you observe is not obvious or doesn’t occur somewhat frequently, there is probably no need to write a standard for it.
• Keep your standard local.
  Remember that a standard is the best known local method to do something. It is what we know for a given situation. A standard may not work in another team’s hands or a different context.
• Your team needs to understand the rules to play the game.
  Without sufficient pedagogy, standards can be misinterpreted. There is a risk for the team to take it as a Taylorist way to get them to do something rather than a tool to help them grow. Before writing and adopting a standard, make sure that the team understands the intention behind it.

In conclusion

While this approach is not an exact science, it is a structured way to keep the learning process going in a team. Of course, we sometimes come back to old habits or try this new shiny methodology that all PMs are talking about. But creating our homemade standards and regularly improving them has shown to be a powerful enabler for every Qontoer to drive personal improvement and team growth.