Nike Engineering
Published in

Nike Engineering

Why Engineers Should Be Invested In Their Product

by Sobhagya Jose

Are you an engineer? When was the last time you had a conversation with your Product Manager about the product you’re building? If your answer is longer than 2 weeks, I challenge you to rethink your motivation for writing code.

Engineers have a responsibility towards creating great consumer experiences, and engineers who are invested in their product’s vision can help a good product become a great product. Engineers can embrace this responsibility by influencing product direction and building the right things — things that may not necessarily be identified by a product manager working alone. In this blog post, I will share the fundamentals of product management, and how engineers can participate in the product management cycle keeping these fundamentals in mind.

A lot of backend engineers will tell you that they are proud of writing great code– from their code base to the architecture of their systems. For example, as part of the Motivation team supporting gamification for Nike Run Club (NRC) and Nike Training Club (NTC), we write code that is clear and functional, using new open-source libraries such as Akka and cats. Additionally, using a mix of internal and open-source frameworks, we make sure our architecture is scalable, available, robust, and easy to operationalize and maintain. However, good product direction is just as important, if not more, as good technology. Without good product direction, a large fraction of your users may not even make it down the feature funnel of a new feature you just shipped– resulting in wasted talent, effort, and opportunity. One way to help avoid this is for engineers building a product to be mindful of what makes a great product, in addition to great code. To do that, channel the mindset of a product manager. Here’s how.

Pillars of product management

First, a good product manager will consider two key pillars of while guiding the development of a product : 1) vision (heart), and 2) data (science). To be a good shepherd of the product you are building, consider keeping these in mind throughout development.


To start, the heart of any product or feature is a vision. A vision outlines what the product wants to be in the future, not only for the benefit of the customers, but also the people building the product. Think questions such as: Who are you building this for? When are they going to use it? Are you solving a problem or delighting the user?

Take Nike’s mission statement for example: “to bring inspiration and innovation to every athlete* in the world.” That little asterisk indicates that if you have a body, then you’re an athlete. This motto, this vision, is the North Star for Nike employees regardless of the role they play– from directors to designers to engineers to program managers to product managers.

Having a vision is crucial to everyday decision making. For example, you can use your vision to resolve a common source of conflict in prioritization of engineering work: tech backlog versus new features. Consider the Nike Run Club (NRC) app redesign in 2016– a major overhaul of its platform architecture motivated by the desire to better support for our users at scale and increase the ability to innovate within the app faster. Despite some initial pushback from long-time users, in the last 2 years since the release, NRC steadily climbed the charts with an app rating of 4.8 stars as of Sept 17, 2018, compared to 4.43 stars (July 1, 2016) before the redesign. NRC has also released (and re-released) an array of great features such as Achievements, Audio Guided Runs, Challenges, Cheers, and Shoe Tagging, all built on the new cloud-enabled infrastructure. Decisions like these — balancing scalability and agility — serve the vision of the product to bring inspiration and innovation to every athlete in the world.

As engineers look to embody the principals of a product manager, ask yourself or your core project team what the vision is for the product or feature set you are creating is. Every decision should clearly come back to your vision. It’s this clear connection that will keep your end-product pure and the end-user experience premium.


The second pillar of product or feature development is data– quantifying the value provided by the product or feature to the users in a metric that business stakeholders understand. These consumer focussed measurements, such as metrics and Key Performance Indicators (KPIs), give both the engineering and business sides of the product a standard metric to talk about the success of the product. Choosing the right metric to drive will serve the customers as much as the business, and it’s important to balance out both needs. A good product manager uses metrics to steer the development of a product as well as gain broad business buy-in, both skill sets that engineers could use to champion their work.

This balance is necessary– a good product can only grow so much without funding, and a bad product with a ton of money (marketing, etc.) thrown at it will never sustain growth. For example, the Lifetime Value (LTV) of app users is a meaningful high-level metric for evaluating the profitability of an app. For a revenue focussed app, LTV can be boiled down to a dollar amount per user, whereas for non revenue focussed app, you can instead use user engagement, or a combination of both, as a metric to drive. That’s not to say that you should shoot down “silly” or “fun” ideas that you don’t expect to make a significant change to the metrics. Be aware of who your audience is, and always do a post-launch analysis; there is always scope for it to turn into a great idea.

Take the example of the Personalization team at Nike Digital working on the Workout recommender for the Nike Training Club (NTC) app. The team, which is made up of engineers, data scientists, and business/product, collectively decided that the key KPI would be driving engagement by encouraging more users to start their first workout. The engineering team leveraged a wide variety of data and iterated on strategy, before moving forward with their technical solution. With the support of their product team, they utilized A/B testing and goal driven development to build the right product so as to Serve the Athlete*, while being scalable and robust in order to be more maintainable. This means open communication between engineers and product teams, inside and outside meetings, as equal stakeholders. The team demonstrated perfectly how to leverage data: “A/B testing results showed that workouts from the Picks for You section were started five percent more often when powered by the Neural Network model than Collaborative Filtering. This way we were able to gain five percent more engagement on top of the 57 percent engagement gain from the initial model!”

Think of your KPI as your anchor. Keep coming back to it throughout the development to see if what you are creating will drive that KPI. If it doesn’t, ask yourself “Why are we building it?”

Participating in the Product cycle as engineers

Now that we know the main pillars of good product management, how do you, as an engineer, start embodying the role of a product manager while creating your product? Here are a few pointers to incorporating into your everyday work mindset:

  • Remember the vision. Think big-picture, even while executing the details. Understand how the feature that you’re working serves the consumer, and how it fits into the business goals of the organization.
  • Participate in the process. This can be done as early as the ideation stage, by way of internal hackathons. For example, the delightful Custom Cheers feature in the NRC app was originally the winner of an internal hackathon! You can also participate in the product cycle at a later stage such as the product design/ engineering design by participating in feature review meetings, which are often organized by product owners.
  • Know the priorities. Product owners are paid to ensure the team, including engineering (and design, quality testing, etc.) are working on the most important problems that provide the most value. Get coffee with your product owner to talk about what your team’s priorities are and why.
  • Win as a Team. While executing the details of your feature, brainstorm and iterate over execution by talking with the other disciplines working on the same feature, such as backend developers, mobile developers, and designers. Doing so can avoid wasted effort by having everyone on the same page as much and as often as possible. Don’t hesitate to have an exchange of ideas with members of different disciplines, as long as you are respectful of each other’s role and domain expertise in the team.


A good example of a healthy PM/ Engineering relationship is Asana. Asana is a web and mobile application designed to help teams organize, track, and manage their work. In her article titled How we develop great PM / Engineering relationships at Asana, Jackie Bavaro, Head of Product Management at Asana, describes the key components of a successful working environment for software development: “At Asana, engineers are involved and can lead product direction from the beginning of the product lifecycle. [1] We gather input from across the company in planning our roadmap, and [2] include all the engineers on a team in research and design brainstorming at the beginning of each project.”

The product launched commercially in April 2012 and was most recently valued at $900M. Besides being a successful company, Asana also received a rare perfect rating on Glassdoor and a place on Glassdoor’s Top 10 Best Places to Work in 2017. It is not surprising then, that the company claims to be a team of peers on a bold mission. The engineering team has a set of guidelines for making decisions that are driven by the company vision, and a culture of goal setting, where engineering and product is equally invested in the final product, while contributing with their respective domain expertise. At Asana, “Engineers appreciate understanding the reasoning behind product decisions. PM’s love when engineers come up with valuable ideas enabled by creative technical solutions.”

Creating an environment of inclusivity between disciplines, driven by mutual respect and a common goal, can result in both a great product and a great work environment. Boom.


Engineering has the power to affect the community for the better and– as a consequence– the responsibility to question the motivation and value of what they are building. There is an opportunity for engineers that are working as part of a larger organization that is not necessarily found on the same scale when working on say, individual side projects. In a large organization, there is a common leadership and in an ideal world, that means everyone is driven by a common goal. Also, for a software development team to be content, productive and delivering results, inclusive decision making and mutual respect to other disciplines are not nice to have, but crucial.


  1. Serving Athletes* with Personalized Workout Recommendations
  2. How we develop great PM / Engineering relationships at Asana
  3. How to Avoid Over-Engineering the Product Role
  4. Are you Netflix or Blockbuster? How a Clear Vision is Vital to Innovation to Innovation

To learn more about jobs at Nike visit



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store