As a software developer, there are some things that you’re interested in just because you’re an engineer:

• Which Javascript framework is better for enterprise front-ends?
• Should I move from Heroku to AWS?
• How do I mount an Amazon EFS Drive inside Docker?

But at Lab Zero there’s one question we put before all others:

“Am I delivering value?”

Some developers hope to get confirmation by asking their boss or their engagement manager, ‘Hey, how am I doing?’--which of course is one way to solicit feedback of all kinds. In addition, we’ve found it’s useful to be on the lookout for raw indicators that point toward value.

Signs to Look For Out in the Wilds of Product Development

If you’re working as a solo freelancer in an enterprise setting, you may see signs like these:

Direct from Users

You see proof of value when users pay for the features you’ve built. Because so much of software development supports other roles and activities, it’s not the most common case to get direct knowledge of users signing up to pay for your software. But it happens, and when it does, it’s a very reliable measure of value delivery.

If you’re lucky enough to have your users in the same company as you (for example, for internal development projects), then you may also hear directly from those users things like, “This makes my job easier.” or “I’m going to get my whole team to use this.”

Even if you don’t get the chance to capture a direct testimonial to your work, it’s a good sign if you know the names and faces of three actual users of the thing you’re building.

From your Organization

From your product team, you may have heard something like: ‘We think users will benefit from a shortcut through this difficult process. What’s the easiest way we could test that?’ When you hear this, you know that your product leader is in a learning mode, and that they are seeking the least-effort way to deliver value.

You may have heard: ‘If X is a problem for users, why don’t they just do Y instead?’ If you hear this, you know that your product leader is engaged in understanding user behavior; a good sign that they’re open to alternative ways to bring value to users. (They’re not locked into solution thinking.)

“Why was the adoption rate of our MVP so low?”

In general, open discussion of questions about things that the organization does not know is a very good sign that value (rather than project completion) is being pursued. Questions, more than answers, indicate that your team is seeking value.

If You’re on a Lab Zero Project

If you’re an engineer on a Lab Zero project, you’ve aligned on Goals and Roles. One of the roles on your team is that of Product Owner. The Product Owner articulates hypotheses for delivering value, and metrics to quantify that value.

So the Product Owner may state a hypothesis like, 

“We think that 20% of our users would opt for a premium offering that contained X, Y and Z. We tested a prototype with users, and now we have outlined what we think is in the MVP. We think we can build the MVP in 4 months. After launching we are going to measure 

• click through rates describing the premium offering
• conversion rate from basic to premium
• churn from premium back to basic
• customer satisfaction solicited through the site

Plus, we’re going to keep talking to those users who participated in our prototype tests, to see how close the delivered software met the mark as they perceived it.

When you hear this, you know that you will be able to look at the metrics defined as part of the effort to see how much value is being delivered.

Another job of the Product Owner is to prioritize new work that generates the maximum value for the least effort. Your input as an engineer on the effort side of that prioritization was during an estimation session. So as you complete stories and epics that have been prioritized, you know you are delivering value.

Your top-tier Product Owner is also going to be listening and looking for keys to unlock value all over–not just in the business and experience spaces but also in the technical space. That means they’ve spoken with you and your technical lead to determine (for example) what platforms may be used to generate more ‘off-the-shelf’ functionality for users.

Your work is represented in quarterly company objectives. One sign that we’re in a position to deliver value is that we hear about our work in our client’s All Hands meetings. Sometimes we see our deliverables represented in OKRs (Objectives and Key Results) or we see our project reflected in PI (Project Increment) Planning sessions.

Does that mean Lab Zero developers don’t have to look for signs of value outside of the metrics? Of course not: our developers are privy to reading and reacting to primary user research (like watching videos of user interviews), as well as hearing the testimonials (good and bad) from real users.

Questions to ask if you’re unsure

If you’re ever unsure whether your project is on track to deliver value, you can ask your product leader to clarify the basics: 

• What happens to the business if we don’t build this? 
• Who are our users?
• What are their biggest problems / needs / frustrations?
• What are our hypotheses about the users? (How do we think we can help them?)
• What could we measure to see if these hypotheses are true?
• What is the last signal we received from users; how was it interpreted; and what did we do about it?
• Is there a dollar value associated with this feature?

Maybe your product manager wrote a speclet and has already captured their best understanding of how the work delivers value. 

Value Anti-Patterns

Here are a few signs that you may be embedded in a development organization that has not yet established value as its ‘north star’.

• You routinely deliver features without any monitoring or analytics built into the epic. (The feature is there, but nobody is looking to see whether it gets used.)
• You build a dashboard for stakeholders to monitor value metrics, but nobody uses it or even logs in.
• When features don’t result in goals being met, you hear only explanations and no open questions.

Each of these value anti-patterns is a manifestation of an organization where ‘being right’ is more important than seeking value. There isn’t necessarily evil involved, but you may want to align your efforts elsewhere if you see these signs. Nobody likes to push a car with the emergency break on.

Don’t Let This One Thing Get You Down

Sometimes developers are disappointed to see their work get decommissioned early. They interpret as failure the fact that the code they wrote isn’t in use.
But that’s the nature of adding value. Suppose that your team set out to discover whether feature version A or feature version B adds more value. And in the experiment, your job was to build the lightest version of A that could (theoretically) beat B. And then it was observed that users who were presented with feature version B churned half as much. Even though feature version A was subsequently decommissioned, the experiment itself was a success. Failure would have been having to reinforce and maintain both versions A and B.

Want (to Join) a Team That’s Always Pushing for Value?

Engineers join Lab Zero because they want to work on a team where value delivery is transparent; where effort is traded against value as the basis for loading each sprint. Where the whole team aligns on goals and metrics for measurement. Where we all know the names and hear the voices of users who inspire us to deliver what they need most.