Image for post
Image for post
Illustration by E. Gallup

Being a (Tech) Product Company

After many years of working in Silicon Valley, Boston, London and Oslo, I’ve realized that I’ve never been in a company that was one or the other- it’s always both.

Jimmy Byrum
Aug 4 · 4 min read

Most companies talk a lot about being a “Tech Company” and then engineers often get frustrated when it seems like Product (and other non-engineers) are calling the shots.

Nothing can happen without decent engineering of course, so in the end it’s there’s not really a choice between being a Tech or a Product Company and the goal should be finding the right thing to focus on at the time and matching the types of engineers in the company to the teams where they’ll do best.

At Vipps, we recently re-structured to organize Product and Engineering as a joint venture with platform/enabling teams and re-aligned product teams. If you’re working on a platform team, you’re working on the engineering focused part of the company, and the product teams are (obviously) focused more on user-facing products.

Good engineering needs to happen in both types of team. I think the difference lies in perspective and prioritization. We’re all working towards the same goal, though different teams add the most value in different ways.

Image for post
Image for post
Illustration by E. Gallup

Product-Focused Teams: Two Distinct Phases

A common startup mistake is to focus on building something amazing and scalable before figuring out what to build. So whether it’s for a new startup or a new project within a larger company…

First: Figure out what to build

The initial focus of a product team is on trying out ideas and validating next steps. This is the least strict phase for engineers. Shortcuts and hacks done quickly to validate what to do next is more valuable than well-engineered code. If hacky code gives you answers in a month, that’s more valuable then amazing code that gives you answers in 3 or 4 months.

Then: Build a solid product

Eventually your team knows what they need to build and then quality engineering leaps to the forefront. In this phase, work should take more time and the engineering should be thorough. You’ll need this to work well in production for thousands/millions/billions! of users.

Repeat?

During this phase we should keep in mind that what we learn while building might send us back to the previous stage where we need to figure things out again.

Image for post
Image for post
Illustration by E. Gallup

Engineering-Focused Teams

These teams also need to first figure out what to build and then build it, but there’s not really any room for hacky code here. The focus is on getting it right as much as possible, engineering is done in a stricter way and quality almost always trumps velocity. These teams enable other teams, so there needs to be some balance between “getting it right” and not blocking too much other work from happening.

When to Switch Phases

This is something that really needs to be a joint decision between Product and Engineering. Engineering needs to be ok with Product taking its time in phase 1 and doing quick hacks/prototypes to validate ideas. Product needs to give Engineering time to replace the quick hack and prototypes with solid code.

Getting the right amount of time for each phase can be a struggle. Product-Focused Teams can find themselves spending most of their time in Phase 1 and then rushing to get to production and to the Next Thing. Engineering-Focused teams can spend too much time “perfecting” their code and thereby slowing down the teams they are enabling.

What is “Good Code”?

It’s contextual. What is the expected lifetime of the code? What questions does it answer or problems does it solve? Short term questions just need code to answer that question. Maybe that’s proof-of-concept code that we plan on throwing away after the proof is proven (or disproven). Long term problems need code that can live a long time. There might be more emphasis on stability and performance with long-term code, as well as readability (over the long-term it’s more likely somebody that is not the author will have to update the code).

Good code is code that provides value. It’s up to you and your team to decide what is valuable and what you want to get out of the code you write.

Image for post
Image for post
Illustration by E. Gallup

Closing Thoughts

On a high level, the key thing here is to not try to make a binary decision about what kind of company we are. We need to try to find the right balance for each of us to contribute in the way gives the most value for the company and for us as individuals- some people like doing very detailed engineering, some people like prototyping, some people like building products- we have opportunities for all of that here.

Vippsbloggen

Vippsbloggen

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

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