There are many writings about the struggle between the speed of feature development and quality of code, products, tests, or any other work product used in the development process.

A short answer is to not sacrifice one for the other.

Here I will focus more on the “how” to achieve this at the level of an organization, focusing on development.

Here are some of my thoughts on creating a product organization that can rapidly, iteratively, and simultaneously have the right level of quality.

Focus on creating Product Engineers #

I think the base of creating a product organization is helping your colleagues become Product Engineers. If this is the first time, you hear about this role (The product-minded engineer) is a great article explaining what a product engineer is. I will write here the main points from that article:

  1. Proactive with product ideas/opinions
  2. Interest in the business, user behavior and data on this
  3. Curiosity and a keen interest in “why?”
  4. Strong communicators and excellent relationships with non-engineers
  5. Offering product/engineering tradeoffs upfront
  6. Pragmatic handling of edge cases
  7. Quick product validation cycles
  8. End-to-end product feature ownership

The article has some excellent advice for anyone who wants to become a product engineer.

Now let’s explore what the organization can do to help people transition in becoming product engineers.

1. Facilitate direct communication with the end-user #

Without direct communication between your engineers and end-users, there is no possibility of having product engineers.

No persona or narrative will create the same connection and empathy as the direct interaction with the end-user. I am not saying that personas/avatars/narratives are bad. They are important to remember, to capture stories, facts … but they will not create a drive; they cannot sustain proactivity; it is hard to identify possible edge cases, which might be new products or new features. They also eliminate a human connection.

There are multiple ways to facilitate this communication. I will just remind you here of two: User Interviews and Design Thinking. User interviews are easy to start with, but I will suggest going into Design Thinking to engage your end-users truly.

Here is a little checking you can do to see where you are:

How many people from your team talked live or online directly with an end-user? If you are less than 50%, this is a bad sign that your team is disconnected from the end-user, and probably they don’t deeply understand the value they create for the end-user.

2. Delegate more product decisions to engineers #

Only after making possible the first point, the organization should facilitate delegation of more product decisions to engineers.

It goes mostly toward transforming the role of the Product Manager to a mentor/coach of the team in helping the team understand the vision and support them in finding ways to achieve it. This will be a hard role for Product Manager, and she will play here a role of a tester, challenging team assumptions, asking for metrics, showing a mirror for the team from a product perspective and making sure feedback goes back to the team no matter if a feature was a success or not.

It might seem that in the short term, this might decrease the successful features released, but in the long term, this will truly create the best teams and will allow you to scale up as much as possible without losing the initial sync with the user and the product.

Reality check:

  1. Who is writing the requirements? POs or the team? If only POs, then you score lower on this. POs should help the team define goals, vision, and objectives, but the team should manage their requirements. If they cannot write requirements, they don’t understand the end-user.
  2. Does your team have access to business metrics? If not, they cannot handle product decisions because they cannot assess their decision-making process and cannot adapt.

3. Open feedback from users #

How does your team handle open to feedback from end-users? When an end-user complains, what does your team do? Do they get upset? Do they blame the end-user? Are they indifferent?

Getting upset together with a lack of action is a bad smell for the product’s understanding of the team. The same goes for indifference or blaming the user.

The right mindset is a curiosity to find you what happened, to explain why.

Here the organization has a crucial role in how it handles failure.

If failure appears as something terrible and unrecoverable, then no curiosity is possible. People will try to hide it as quickly as possible.

4. Testers as representatives of end-users #

The organization should support testers to become representative of end-users. They should be the ones who point out that this feature does not provide value for the end-user, or this flow is too long.

Testers should become the go-to for any team member who wants to validate/invalidate an assumption.

Also, testers should test assumptions made by product managers to validate that what is built is needed by the end-users. This is an essential point because the work of product managers should also have associated tests. Reviewing requirements is not testing product assumptions. It mostly tests how the requirements are written. To test product assumptions means to ask questions about what the end-user wants and how well our product can solve user problems.

5. Working in plain sight with assumptions #

The team should acknowledge their product assumptions, detail them, and find ways to measure validity.

The market/end-users should finally make the validate step of an assumption. Any other validation should be looked at as being flawed and used only when there is time pressure or a limited budget.

6. Support ideas from anyone #

Another way to support your developers and testers to be more involved in the product is to consider their ideas. Don’t just dismiss them because they are technical. A lot of innovation in IT comes at the crossroads between what is technically possible and how that can be used to solve in a new way user’s problem.

I know that the first thing that comes into mind is to form a kind of jury with people from business and technical and invite team members to pitch there. It is a good idea if and only if the team members are encouraged to understand what a product decision is.

Don’t just vote what ideas are okay and which not, but explain to the team members why and the idea is not suitable for the product or end-users. Have a debate about that and encourage them to get real feedback from users before pitching their ideas.

7. Be more narrative and explain decisions #

Especially when working remotely, communication about why a decision was taken, and how the decision-maker got it is very important.

This is more important if you want to empower your engineers to become product engineers.

Here is an example of what should be shared when presenting a new feature:

  1. Who are the users who will mostly use this?
  2. What problems will solve for them? How are they solving their problem now, if any?
  3. Why do we think the users will adopt this feature?
  4. Why is this feature more important than others in our queue?
  5. What are some assumptions that we took into consideration when deciding this?
  6. What are some metrics that will show the success of the feature?
  7. What are some metrics that will show the failure of the feature?

This could be a starting point to have a conversation about a proposed feature by a product manager, and the most important thing to focus on is the word conversation. It is not only about writing answers to these but having a conversation about the feature with the team and openly answer their questions.