Tips to better contribute to a product team as a Junior Developer

Over the past couple of weeks, my colleagues and I at Stairway have been working hard to improve our product process and become a more empowered and collaborative product team. I’ve recently read “Inspired: how to create tech products customers love” by Marty Cagan to help understand what a successful product team looks like.

If you’re a junior developer working in a product team who’d like to know how to make themselves more useful, here are the tips I feel will help you.

1. Learn about the product process and the responsibilities within the product team

As a Junior Developer with no prior technical background, product was one of the first terms I started hearing a lot of and it was very abstract to me. What is product? What do product managers do? What is their goal? Bring in other terms like “product discovery” into the mix and I realised that it was a very important area of the company that I had no real understanding of. I also didn’t think it really had much to do with my day to day role aside from working with the product manager to implement features and shape designs but I couldn’t have been more wrong.

An effective product team is one that works collaboratively to help the product manager to determine how to discover and build a product customers will love. And in order for you to effectively contribute to this team, it is crucial to understand what a successful and collaborative product team looks like (and likewise what it doesn’t look like). Ultimately, you need to learn about everyone’s role on the team and how your job helps them do their job.

That being said, here are some resources to help you get started:

• Inspired by Marty Cagan. I cannot recommend this book enough. Although it is geared towards Product Managers, Marty dissects each role in the product team as well as what a correct product process looks like. View here.
• Silicon Valley Product Group Blog. A blog sharing best practices around how to build innovative products customers love. View here.
• Lenny Rachitsky Newsletter. This was recommended to me, it is a newsletter around product and growth, particularly useful if you are interested in working in product. The monthly email is free with the weekly emails requiring a paid subscription to access. View here.

2. Learn about your company vision and strategy

Once you have a good understanding of the product team, you should take the time to understand your company vision and strategy. I am sure you probably already have good knowledge of this but I would still advise that you revisit it. You’ll view it with a newfound perspective on how a product team and your role fits in with this wider goal.

3. Participate in the research phase of the product discovery process

Writing products comes from the deep understanding of the users needs combined with an equally deep understanding of what’s just now possible - Marty Cagan

The product discovery process is a hugely important part of the work of a product team. It involves studying users to understand which features or products to commit resources to and build. I won’t go into too much detail about it now but here is a useful article if you’d like to learn more.

Evidence gathering is an important part of evaluating whether a feature should be prioritised and built. However, developers typically aren’t as involved in this process as they could/should be. The work of a developer mostly involves evaluating features/designs being worked on by the wider product team and implementing features that are ready for development. Thus, product discovery happens before developers typically get involved.

However, engineers have a lot to contribute at this stage and so you need to play a bigger role in the initial stages of product discovery. More specifically, this involves keeping up with the latest data insights on users and also playing an active role in querying and analysing the data that you are collecting.

At Stairway, we use BigQuery, Metabase and Amplitude to query and analyse data which are then shared in slack channels and discussed in meetings. This helps us to have a clear sense of direction with feature development as well as brainstorm further lines of inquiry for research.

If your team conducts user testing sessions, join them and you will see the benefits it provides in helping you learn more about your users and the technological solutions that will make them love your product more.

4. Consider how analytics will be factored into every feature you work on

In order to be impactful for your users, the decisions of the team must be data-informed. And in order for decisions to be informed by data, data must be collected! And not just any data but the right data to answer the questions you are seeking to answer.

Are you involved with conversations around analytics and how they will be implemented into new features? Are you aware of the analytics that you are collecting for the features already in production? What more could you be collecting?

One thing I try to do when a new feature is being considered is to have a think about what analytics we would need to collect to evaluate the success of the feature.

• Is it important to know how many unique users used the feature?
• Are we interested in seeing if this increases the number of active users?
• Are you conducting an A/B test and comparing one data set to another? What difference are you expecting to see?

Thinking in this way will help you to develop a data-driven mindset where decisions made are based on analytics and experiments and it will make a difference in your ability to conduct data analysis yourself. In terms of the goals of the wider product team, collecting the right analytics facilitates the crucial product discovery phase of the product process. As a junior developer, get involved in this!

5. Share your findings and ideas with the team regularly

An effective product team is one that is collaborative. Instead of thinking about the team as having strict roles that everyone is assigned to, roles should be a bit more flexible and involve discussions with other team members to contribute a fresh perspective.

Part of being more collaborative is knowledge sharing. This could involve sharing observations from data, user research or your own ideas you have to improve the product. At Stairway, one way we do this is by having a weekly show and tell session. Everyone discusses what they have been working on as well as any new insights and learnings they have discovered during the course of the week. We discuss everything from designs, to data, to new ideas for product and it works really well in facilitating collaborative decision making.

Sharing ideas and knowledge is particularly important for engineers as they are often the best source of ideas as they have the knowledge required to consider how user problems could be solved using technology. Engineers are aware of how the system works and how easily something can be achieved.

If you don’t have a culture of knowledge sharing in your team, try to implement it. You could make a slack channel (or another equivalent) where people post new insights they’ve found or anything they’ve been working on to get feedback. Working in this way will help facilitate continuous improvement which is an important ingredient to success in a product team.

6. Review and feedback on features as early as possible

Developers typically review designs and features when they have been fleshed out by the designer and product manager and even tested in some initial user testing sessions. However, developers can provide value much earlier in this process, even when features are just ideas and designs are just simple drawings. The main benefit of this is that it makes the design process and feedback delivery easier. Sharing goals and ideas early benefits the whole team in terms of time and effort and prevents any large changes to designs being made late in the design process.

If you are typically evaluating features at a later stage, discuss with your team to see if this is something that can be changed to bring the review process forward.

If you struggle to think about how to evaluate a feature, consider these four product risks:

• Value risk (whether customers will buy it or users will choose to use it)
• Usability risk (whether users can figure out how to use it)
• Feasibility risk (whether our engineers can build what we need with the time, skills and technology we have)
• Business viability risk (whether this solution also works for the various aspects of our business)

Whilst all risks should be considered when evaluating a feature, engineers should focus the majority of their attention on the feasibility risk, and take responsibility for it.

You can read more about the four risks here.

Thanks for reading this article. I hope it has helped you to understand how you can better contribute to a product team and think about new ways you can get involved in your team's work outside of development.