Market-Engaged Engineers Can't be Replaced.

In my career I’ve been a software engineer, an engineering leader, a product leader, and a senior executive. But I have always come at the problems I solve in all of these roles as an engineer first. There are a lot of different product-development org structures out there, but once you get to a certain size it’s still pretty common to have a separation between Product Managers and Software Engineers. When you have this separation, the MVPs on the team are almost always “Product Engineers” who span both disciplines. But how do you become a Product Engineer? What does your engineering background lend to product discussions? What will be missing for the user if the product definition is determined solely by design and product managers?

Your product strength as engineers is systemization.

The user’s experience and expectations are the most important elements in making a good software product. Product managers are good at adding customer needs, use cases, roles, and personas to the Product Definition. Your job as engineers on the Product Definition side of the fence is to get your users into Flow.

As product engineers, you need to understand

• who is going to use your system
• what they want to do within it
• what they expect of it between sessions

You need to develop a common understanding across the whole engineering team about the what, the why, the how, the how often, and what’s likely to trigger user frustration. And you need to create the metaphors and expectations people will learn in order to interact with the system. This means things like:

• Lists and tables always have a sort order, and that sort order is not different in different places for arbitrary reasons.
• If state is saved on the frontend between sessions, the state is useful to the user and complete. If someone drafts a form and they accidentally close that tab, there can’t be arbitrary things in that draft that saved and others that didn’t.
• If you create a behavior like “setting permissions,” and it is exposed in several places, it needs to work the same way in each of those places.

I recall an instance where we were adding signup slots to our calendar implementation. I got a design for a recurrence section of the dialog, and was immediately baffled why we’d have two different ways to create a recurrence rule on the calendar. If I hadn’t asked the question of “why aren’t we re-using the dialog we already have?” it wouldn’t have been asked. If it had been handed to an offshore contracting team they would’ve just built it. If it’d been handed off to a (theoretically competent) AI, it would’ve just been built. Product Engineers are the ones who look at a flow and a design and say “Is this consistent?” And that’s a value-add no amount of outsourcing or AI assistance will replace.

Reduce the number of conditionals your user has to keep in their head to use your system without making mistakes. If your user has to remember “I can’t add calculated fields until my form is out of draft”, then make sure you agree with the “why” and that it will be obvious to the user. If you receive a product requirement that introduces arbitrariness, show the person arguing for the requirement why it makes using the system harder for the user.

Show up for meetings where you have nothing to say.

What? What a waste of time!

Trust me. Sometimes your job is just to listen and stew.

Listen in on meetings where product definition is being discussed, even if you’re afraid you’ll have nothing to say. And in those, don’t multitask and keep an editor open or read Slack while you do.

The parts of a meeting you’re in where you’re not adding what you came there to add are not a waste of time. They’re time for you to be taking mental notes or working out the “flow” of the product you’re working on. Talking is not the unit of value in meetings. Your job is just as much to listen to what features are being proposed, and what problems are being solved and think about how you might close the gap between a product being a “loose collection of features” and it being a “cohesive system that streamlines every aspect of a user’s day”

Model workflow and environment.

This is about happy paths and unhappy paths, and also about understanding whether you’re creating something that’s better than the alternative your user is already accustomed to.

Workflow

How long does it take, and how many steps are there to the user getting our model task done in the “control case” of them not using our product? If we can’t do better (or add “networked value” through integration with our suite) we should be going back to the drawing board.

Once we’re past that initial hurdle, we still have to ask ourselves more questions to arrive at a great experience. How does one action lead to another? Are we interrupting our user in their tasks with notifications? If we have to interrupt them to ask for information, do they have to navigate somewhere else to get it? Are we collecting useless data because that’s what’s done and we didn’t think about it?

I went into town the other day and tried to pay for a parking meter. I could either insert change OR I could scan their QR code and spend 5 minutes in the sun trying to enter all my personal info into my phone to create an account and add a payment method (no Apple Pay) just to put $1.50 into the meter. Why do I need a unique username and a password with arbitrary required characters and to give you my email and uncheck “subscribe to receive important alerts and updates about parking” to pay a parking meter? I don’t, but someone said “We need account creation” and it was built from a perspective of “this is what account creation screens I’ve used look like” with no regard to the actual use-case. Also, what possible reason could I want to subscribe to a newsletter for municipal parking?

But while you’re making up arguments in your head as to why they legitimately need all this extra crap, ask a different question: Why should it take me 10 seconds to fish out change and put it in the meter, but 2-5 minutes for the “convenience” of paying by phone?

“Well, you only have to create the account once!” Sure, for this town, but the next town uses a different system so if I have business regularly in three different towns I have a parking meter account in each, a password manager entry for each. I have to unlock 1Password and allow it to fill the password, set a time, click ‘confirm’ and … this is why I keep wanting to put my phone through an industrial rock crusher.

Workflow matters.

Environment

What does my code need to know about its environment in order to run and connect to services?”Postgres connection strings, S3 buckets, container organization and connections. Infrastructure setup in Terraform and Helm.

Another aspect is the user’s perception of your application’s environment: “What do I have to do to ensure the user feels like the system is responsive, consistent, navigable and reliable?”

• Which things belong async, how does the user know that it’s async, and how do they know status of async jobs?
• How do we let the user know if a connection to an external service fails, and how do we let them know when they have to do something about it?
• What’s acceptable in terms of response time and error rates, and how does that push down into modeling everything else (like page sizes, payload shapes, polling vs. streaming and frequencies, etc)?
• How do stale notifications and alerts clear out?

For this one, say you have a calendar system and it sends time-sensitive notifications through Twilio. If Twilio goes down for 45 minutes (not unheard of) and your system has a backoff-retry loop for sending notifications, you have to make sure you don’t send a stack of notifications for appointments that have already started and/or ended.

And finally a part of modeling the environment is modeling pubs and subs. What events in other applications are important for the experience in this application? What events in my application should propagate outwards to others lest it reduce the positive experience all around?

Pubs and subs can be internal to your organization or external. Where I worked, we had several products we’d acquired through M&A. If a user were to change their address in one application, it should propagate to all applications.

Push yourself to think bigger, earlier.

The point of all of this is that Product Thinking by nontechnical people alone will not make a good product. But a corollary exists to this, and that’s “product thinking by engineers too late in the game is ineffective.”

Ask questions on tickets, great. Definitely do that. Clarify details of a Figma design attached to a ticket, sure. This is great, but at this point in the game these are destined to be tweaks. As I’ve been explaining, though, great product engineering starts systemwide.

The most important thing in this article if you take only one thing away is this: get into product definition discussions early and listen, even if you don’t have anything to say.

Everything else will follow from that. Listen, think, walk yourself through what the product is trying to accomplish with this new development. And as a product engineer, remember that your goal is to keep your product from becoming a “loose collection of features,” in favor of becoming a “system that gets your users into Flow and keeps them there.”