Development Market Research Product

Focus on Why, not How

Most engineers focus on HOW to do something – not whether they SHOULD.

Engineers tend to be very intellectual – curious about how to solve problems, because that’s fun. But asking whether a problem should be solved is something everyone should be doing, at every level of an organization.

Dan recently started working for a great mid-sized startup (a departure from many years of ideating & building MVPs. During his interview, he was given a coding task – and part of the ask just didn’t make sense from a product perspective. He didn’t see how adding this feature would benefit the customer & the business, so he didn’t do it. 

When Dan explained this to his interviewers, they were surprised – apparently no one had ever done this before. But they loved it. Because all organizations need contributors who can improve the bottom line of the business, not just execute a development task.

The Cost of HOW 

The challenge here is that most organizations aren’t structured to empower engineers to make product decisions. And a result, it’s a skill that many engineers never cultivate.

And this makes sense – there’s a lot of value in splitting out functions and teams as businesses start to grow. But when your engineers are disconnected from the customer, the market, and why the product exists to serve them, there’s a cost, from…

  1. Wasted development dollars, to
  2. Lower employee morale (and potential burnout), to
  3. A “kitchen sink” product – rather than a lean machine focused on customer needs

Don’t get me wrong – having engineers who understand how to do something is critical. But HOW is only valuable after you’ve decided the SHOULD. 

In fact, sometimes the best solution is one where you have to write no code at all – and that saves time and money.

But this runs counter to a lot of today’s work culture. We equate seeming “busy” with contributing value – and as a result, we’ve trained our engineers to do those tasks in JIRA, simply because checking them off shows their managers that they’re productive. 

And when those tasks include features that aren’t really impactful? This has huge implications for employee morale because no one wants to work on something that no one will ever use.

Creating a SHOULD Culture 

In a perfect environment, everyone is comfortable saying NO. The default is, we don’t work on something unless a customer really needs it. Because too often, the impulse is “this is exciting, let’s build it”.

Now, let’s say you do have an engineer (or you are an engineer) who IS thinking about whether something should be done. If that engineer isn’t involved with the product process until the development stage, saying NO threatens egos upstream – because people have spent a lot of time and energy up until that point. 

In order to make this a part of your culture, you have to involve engineers at the beginning of the product ideation process. This has 2 key benefits:

  1. Engineers are deeply connected to the customer, their needs, and WHY a product is being built – so they CAN say no later on, with good reasons for doing so.
  2. Product / business stakeholders get early technical feedback, which can totally change how they approach requirements.

In practice, you’d have at least 1 engineer who will be working on features involved in product discussions from day 1 – from inception, to execution. So in theory, by the time a product brief is delivered to your developers, SHOULD has already been addressed from their perspective.

So that’s a perfect world. But in the real world, where most organizations silo product decisions from development tasks…

How can engineers develop a SHOULD mindset?

Think critically about whether or not this thing you’ve been told to work on makes sense to you. 

If it doesn’t make sense to you, then either it’s not being communicated well enough, or the inherent value isn’t obvious. And if the value isn’t obvious to YOU (who know your company and your product), it isn’t going to be obvious to someone who is a customer. 

Now, if you don’t feel like you understand your customers’ needs, go find out. Product marketers can be a great place to start. Talking to customers can be even better. 

Because if you don’t understand what pain points you’re trying to solve, and who you’re solving them for, a task will only ever be a task. Key into the why and the SHOULD, and suddenly your code feels like real, tangible impact.

Development Market Research Product Saving Money

Build an MVP (Not Everything but the Kitchen Sink)

The Challenge

One of the top mishaps we see with startups getting off the ground is trying to build everything but the kitchen sink. At this early stage, it’s easy to dream big about what could be – those sleek UI elements that’ll jazz up a user’s experience, that nice-to-have that would really make the product pop, and the handful of features needed just to meet comp. You’re vision-boarding what your business will look like – which naturally means that you’re thinking about those key market differentiators, and the polish that you’d expect from a fully-fledged product.

But watch out – while this is all critical to making your business a long-term success, trying to building too much for an MVP can kill your product.

MVP = Minimally Viable Product

Consider the Pareto principle. In this case, we tend to see that 80% of the action happens in 20% of the product. That 20% is your MVP, and will capture most of what users will ultimately get to do with the product. The other 80% may be necessary to the product’s ultimate success, but isn’t necessary for launch. Ask yourself – are these features necessary for the product to be usable at launch? By necessary, we mean will the product cease to function without them or lose its core value proposition? Or could they be added in V2 or V3?

A Lean, Mean, MVP Machine

So why does this all matter? Why not just build the product as you envision it for round 1? A few reasons for this: 1) Time, 2) Cost, and 3) Investment.

  1. Time: The longer you take to get to market with an MVP, the longer it’ll take you to start turning a profit, and the more runway you’ll need to self-fund.
  2. Cost: The more features you add, the more expensive your MVP will be.
  3. Investment: The purpose of an MVP is to test the market – do they really want your product? What do they like / dislike? Is it solving the problems you thought it would? If it turns out you’re wrong, by building an MVP, you won’t have invested all your $$s in a product that isn’t quite right. It’s easier to add features that you KNOW are right, rather than test features that might be wrong and have to go back and re-work them.

Ultimately, your biggest asset as a startup is your ability to be fast and flexible. You may not have all the money in the world, but you can do things quickly to respond to the market. Learn something new about a competitor? Change your product. Partnership opportunity just came up? Add the one feature they need to make it happen. Not quite sure what customers want? Test your hypothesis on the cheap, then pivot if you’re wrong.

The net-net

The purpose of an MVP is to test an idea with your market. Building a lean MVP saves you time and money, and gives you the flexibility to change course if needed. Features can always be added later when you have the resources to do so, and the market validation that you should.

Ready to streamline, but don’t want to lose track of those extra features? Sign up for our email list to get a preview of our upcoming post on  how to create your product roadmap.