In my most recent roles as a frontend engineer at a $500M DTC meat subscription eCommerce platform serving 400k members, and a $50M daily fantasy sports platform with 200k+ users, I build dozens or hundreds of features. As a frontend engineer, that's how I thought of them: features.
But what they actually were were solutions, and what I actually was was a product engineer. These were solutions to problems for our customers, and when I'm building a software platform actually I have two customers
The end user, buying the meat or playing the fantasy contest, spending the money that pays my salary and getting value from my company's product, and
The business customer, who is concerned with finding ways for that end user to get value from my company's product so they'll spend more money.
My job an engineer is to build ways for my business customer to accomplish their goal, so that the end user can accomplish their goal.
That is the job of a product engineer. That is the job of the product trio: Product Owner, Product Designer, and Product Engineer.
My job starts with an ask. Here are a number of asks and the features my team and I wound up delivering.
Build a page where our meat-buying customers can browse recipes and filter them, so that they can more easily find ways to use their meat, so that our business customer can keep users more engaged between orders (Browse Recipes)
Build a way for our business customer to highlight certain products, and for our meat-buying customer to easily find products they're interested in (Filters on the All Products page)
Build a new game mode so that our business customer has more attractive ways to get users to spend money, and our fantasy-playing customers have more fun ways to play (Two new game modes)
Build a way for our business customer to make money during busy holiday shipping periods, helping our meat-buying customers keep buying meat any time of year (Delivery Window Overrides)
Build a system for our business customer to offer exciting deals, giving our meat-buying customers incentive and urgency to make purchases. Then, rebuild that system so that bad actors can't take advantage of it – so our business customer can keep using it without losing money (One Per Customer promotion, and bug fixes)
Build a tool for our business customers to create and manage offers, so that they (still the business customer) can market them to the user more easily (than they did before Shopify) so that our meat-buying customers will see more value in subscribing (Offers Tool)
Build a system for our business customer to run sales so we can get meat-buying customers to buy more meat (Shopfiy Deals Migration, Rules Engine)
Build our main product listing page so that it loads more quickly so our business customer doesn't lose customers and the meat-buying customer can buy their meat more quickly (Performance work on the All Products page)
Build a way for our business customer to highlight a certain product they want to sell and engage the meat-buying customer with a way to use that product and therefore a reason to buy it (Shop-By-Recipe feature)
Build a frontend application that makes it easier for our business customer to quickly and independently update content and product information, while letting our meat-buying customer buy meat in the same way they always did, and with a faster application (the entire migration of our application from Gatsby to Remix, integrating Contentful CMS, and moving the product merchandising to Shopify)
That ask, whatever it is, has some level of ambiguity. Maybe the ask is a problem to solve and we need to figure out the feature to solve it, maybe it's a feature that solves the problem and we need to figure out how the feature should work, maybe it's a fleshed out product with a design and we need to figure out how to build it.
No matter what level we start at, there's some amount of ambiguity, and it's my job, as a member of the product team (the 3-legged stool of product, design, engineering) to find enough the questions to ask to clarify the ambiguity so that we can actually execute to solve the problem.
It's also my job to recognize that even in the cases where the information we get is closer to execution (i.e., a feature rather than a problem, a design rather than a feature), there is always hidden ambiguity at the earlier levels that we need to be responsible for. Is this feature the right/best solution to the problem? Does this design for the feature take into account all the ways the end user might use the feature? Does it actually solve all the problems that our internal customer has? Does it consider edge cases, ways things can go wrong?
It's my job to ask enough of those questions to resolve enough ambiguity to execute and deliver a minimum viable product. I bolded that because the actual meaning is important, it's not just the ambiguous "deliverable."
Minimum: There's so much ambiguity. There are so many questions. There are so many things you can't control, especially in the frontend: browser versions, screen size, network speed and health, device constraints, things the end user can do and places they can click that we never thought of, accessibility concerns – the list goes on and on and on. There are so many features our business customers want this tool to have. You can't spend the time or resources to answer all of the questions, to implement all the features. What can we deliver that solves the most important problem that we can get up off our asses and build?
Viable: What is that most important problem? There may be a few of them. But which are the most important? What are the features that, if we release with those features missing, it's not worth releasing? How ruthless can we be in answering those questions? Where are we just being afraid to get started, or trying to get it perfect, and how is this slowing us down? (And is asking that last question diverting us from getting started?!?!)
Product: Remember the ambiguous problem you started with. At its root was your business customer, your company, needing to make more money. The time and resources you spend building this product, solving this problem, cost money. Your success not determined by how "perfect" your solution is, or how "perfect" your code is, it's determined by whether your customer (the business you work for) gets more value from your work than they put into it.
Receiving an ambiguous problem, asking the questions to reduce the ambiguity so you can execute, and delivering the MVP, or the next iteration. That's the job.
Top comments (0)