Getting Product Management and Engineering in Sync

One of the most important relationships in a technology company is between the product managers and engineers.1 This relationship is the key to successful product development. Each position plays an important role on the product development team to help with the goal of producing the best product possible.

The role of product managers is to be the liaison between customers and the rest of the development team. They see and talk to customers every day. Product managers have a good feel for what the customer’s frustrations are and where the holes in the product may be. That means product managers want to focus on fixing existing customer problems and adding new features to make current customers happy and also attract new ones.

The role of engineers is to build and implement the product that the product managers have outlined. Because they have to deal with the actual implementation of creating and maintaining the product, they have to focus on current technical limitations and resources required to make a new feature a reality. Engineers have to make decisions about the product that won’t prohibit or detract from future additions.

Finding the balance between these two different positions’ incentives is the key to a great product team relationship. To find that balance, the two sides need to better understand each other’s motivations.

Let’s start with the motivations of a product manager. Product managers are judged by the product their team produces. They are motivated to make customers as happy as possible because customers are the ones who provide the signal of the success of a product. This means that product managers have a strong reason for listening to their customers and trying to build all the features they want.

Engineers are also judged by the product they produce but with slightly different criteria. Instead of being judged by the feature set a product contains, engineers are judged by the quality of the implementation of the product. This means things like having a product that is bug-free, fast, and scales is the most important thing for engineers to focus on.

So, while the two positions have a similar goal of producing a quality product, their specific motivations are different. This can cause problems within the development team if they are not understood. It is the responsibility of members in both positions to understand each other. This means communicating with each other about why certain decisions are being made.

When a product manager comes to the engineering team saying they need a feature built, that manager should detail to the engineers why that feature is needed and outline how it will help both current and future customers. And when engineers push back on a new feature, they should have specific reasons why they have hesitations for implementing a new feature and explain to the product manager how it might affect the product in the short and long term.

Making sure that everyone on the product team stays in sync with each other is a key to a successful product. We all have different motivations and incentives in our day to day roles but must understand the bigger picture and work together to build the best product for our customers.

  1. Not to take anything away from designers. Designers have a very important role in the product development process as well. This post, however, will just focus on the relationship between product managers and engineers. But know that designers play an integral role in the product development process as well.

How to Utilize Engineering Resources Early On

One of the main challenges for technology companies early on is the lack of resources. When you’re starting out, you do not have the ability to have teams of people dedicated to each problem you face or idea you have. This means you need to be creative and smart about how you use the resources you do have available to you.

In working with technology companies, the lack of engineering resources is the one we see most often. So how should you use this scarce resource? Maybe you’re thinking that the answer is obvious and that you should only dedicate engineering resources to work on product. You aren’t wrong necessarily (especially if you make good product decisions early on) but you should consider all your options. There’s a time and a place for everything and you must consider your company’s specific needs.

A good question to ask yourself and your team is what will separate your company from its competitors? The most obvious one is your product, hence why you may be thinking that dedicating your scarce engineering resources to your product makes the most sense.

But you should consider how dedicating a few engineers to the sales or marketing efforts of your company might make a difference. Maybe having one engineer spend some of her time working with the marketing team could have a major impact on the leads your company generates? Or having an engineer on your team spend time with your sales team to develop tools that might make closing sales that much easier? Hard to imagine how that wouldn’t have a positive impact.

Again, it all depends on your company’s specific needs and what kind of skills your engineering team might have. Perhaps one of your engineers has had experience building drip marketing campaigns at their old job and can get one up and running fast. This helps enhance another (most likely) limited resource, your marketing team.

We’d be remiss if we didn’t also mention that you should look for existing tools to help augment your early team. A lot of founders early on are cost conscious (we think this is a good thing!) and therefore shy away from spending money on things like design themes, email templates, or automation services. But compare the cost of these items with the cost of an engineer. If your company doesn’t need to differentiate itself by using a customized sales system then don’t roll your own, pay for a service to help you out. There are a lot of really great services already out there. Don’t reinvent the wheel unless you’re a wheel company.

So when starting out, consider the resources that you have now and how you might best utilize them to give your company a leg up on your competition.

Cost/Benefit Analysis of Early Product Decisions

Many of the decisions made by a company early on can have a lasting impact. For example, early hiring choices can influence the type of culture your company adopts. Another area where early decisions can have a big effect on a company down the road is product development.

All companies weigh the costs and benefits of product decisions. But these decisions can be especially important in the beginning. The choices you make about your product in the early days can affect the types of people you end up hiring, how well your product will be able to scale, and the financial costs of maintaining and improving your product.

Speed vs Scale

One common challenge that all early-stage companies face is choosing between speed and scale.1 On the one hand, the quicker you build something you can test in the market, the more information you can gather. Yet on the other, you want to build a product that won't fall apart as soon as you get customers using it.

There is no one answer to this challenge but as an early-stage company, you should emphasize speed over scalability. The reason speed is where you should focus is because you need to test your assumptions before worrying about anything else. Of course you want your product to work when you have lots of customers, but first you need customers!

New vs Old

Another area where early-stage companies consider the costs and benefits is when deciding between going with the latest and greatest or sticking with the old and tried. In particular, we've seen a lot of teams spend a lot of time debating what technology stacks to use for their product. Do we go with the new or the old?

Going with the new option is attractive because everyone likes new things and because the new capabilities might help give you an advantage over your competition. Yet, because it is new, it includes a lot of overhead to learn how to use it and a lack of resources to help. While sticking with the old option has the benefit of familiarity and knowing what to expect, it also may have less features and fail to get your team excited about it.

This choice again does not have one easy answer. But as mentioned, because your company is new, you don't know what your customers want yet. By adding the challenge of having to learn a new technology stack, your increasing the amount of things you have to overcome before you even build anything! If you go with the old but known option you know better what to expect. It will also has the added benefit of helping with speed since familiarity will help you develop your product faster. As your company and product grows, you can always choose the newer option later on.

Every company and product team will be different. And because you are different, you may have a different cost/benefit analysis. But the most important thing to consider when making early product decisions is taking a step back and looking at the bigger picture. Are the choices you make what's best for your company? Or are they based on your own self interests?

  1. Speed here refers to how quickly your team can build a product to launch into the market, not the speed of the product itself (though important itself)

Don’t fall into the trap of creating a product for investors

Many companies run into problems early on because they create their products for investors instead of for their customers. Despite it seeming obvious that you should build your product for your customers and not for your investors, in reality this is actually much harder to do.

The problem lies with the desire to impress investors. Anyone trying to raise money can fall into this trap, even seasoned entrepreneurs. It’s human nature to want to impress others, especially when we’re trying to get them to give us money! Beyond trying to impress investors, you also are more likely to listen to their product inputs because of their experience and the cloak of authority that comes with their position.

While you should definitely listen to what your investors and potential investors say to you, you should also be cautious. Investors have a lot of knowledge when it comes to what’s going on in your particular industry. They get lots of pitches from your potential competitors. They might be talking to other CEOs in your industry but not customers. That’s your job. You’re in the trenches day-to-day talking to customers (if you’re not early on, you should be!). And ultimately it’s customers that make your business.

Yes, raising money can be important for the success of your business. But the most important thing of all is having customers. You want to know what will help you raise the most money? It’s not building the features that potential investors tell you to build, it’s creating a product that attracts lots of customers.

So as you’re raising money to help build your company, each time an investor gives your his or her opinion on what should go into your product ask yourself if that feature will benefit your customers. If the answer is no, forget about it. If the answer is yes, then add it to the list. Just be sure to not fall into the trap of creating a product for investors.

Remote Teams: The Good, The Bad, and The Ugly

In today’s day and age of technology companies, having remote workers is very common. In fact, it is more likely the rule rather than the exception. Most technology companies today have at least a few team members that are remote.
Remote workers are often thought to be apart of the product team but this isn’t always the case. As technology changes and improves, members from other teams are joining the remote workforce.
But having members of your team working remotely is a challenge to manage, even if it’s only a few. Many team leaders don’t have experience managing teams of remote workers because it is such a new trend. It is even more challenging when managing “hybrid” teams. Hybrid teams are teams where some members are remote and some members are in the office with you.
We’ve worked with many teams who have faced these challenges. Here are some of the lessons we’ve taken away.

Good Communication is Key

We’ve all heard it a million times that good communication is key. As much as it might sound like a cliche, it definitely rings true when managing teams with remote workers. Almost every problem with remote teams stems from poor communication.
When you’re in the same office as your team members, it is much easier to keep everyone on the same page. If you need to talk to someone, it’s as simple as walking over to them or grabbing lunch together. Yet, when members of your team may be across an ocean, this obviously is impossible to do.
The most effective strategy we’ve seen for communicating with remote team members is write down as much as possible. It’s better to over document then to only document things you think are important. With existing tools like Slack, Dropbox, JIRA, Google Docs, etc. you have no excuse for not documenting everything.
This is a great strategy even if you don’t have any remote members. The reason it works so well is that whenever anyone has a question about something, whether they are remote or not, they have some place to look. It provides a recorded history of all the thinking that took place, gives everyone a better perspective, and keeps everyone on the same page.
This is especially true when working with remote members across different time zones. You don’t want to waste a whole day of work because someone didn’t have the latest specs so they ended up building the wrong feature. That’s frustrating for everyone and something that can be addressed if you took the time to document everything.
Every team is different in how they go about documenting things. But the best strategy we’ve seen is to have company wide documents (processes, tools, culture, etc.) and team specific documents (product specs, sales scripts, etc.). You should also use a communication tool that records everything said and has searchable archives. Good examples are Slack and email, but there are a tons of tools now that do this well.
All communication should also be open and available to all members of your company! Not only to the members of specific teams. You never know when someone from another team might need information from another team to complete a task. Teams that are more open with information typically function better than those who closed and siloed.

Include Remote Workers in Everything You Can

This relates to good communication: be sure to include remote workers in as much as you can. Even though they might not be sitting across the room from you, remote workers are as much a part of your team as the people who are. That means you should treat them that way. It’s easy to forget remote team workers, as the saying goes “out of sight, out of mind”, but you need to overcome this bias. Nothing creates more team tension than the feeling of being on the outside looking in.
Include remote members in team meetings (only if needed), no matter how big or small. For example, if your team does daily standup meetings, include your remote workers. Even if they are in different time zones, find a time that can work for everyone. If you can’t find a time that works for everyone, use creative solutions to get everyone to participate. Have them record a video of their part and play it during the meeting.
Another great way to include remote team member is to have off-site company gatherings. Some of the best functioning remote teams that we’ve seen do this quarterly or annually. This is a great way to get everyone from the company, remote and local, to meet, hang out, and get to know each other. This is a great idea because it puts a person with a name. Often with remote team members, you don’t get to know them as well which contributes to the feeling of being left out.
When you actually get to know the members of your team who live across the world, you care more about them and so are much more likely to not forget about them at the next team meeting.

Build a Culture Around Remote Work

Finally, create a culture at your company where working remotely is normal. There is still a debate amongst companies about remote workers. Some think working remotely is a negative thing, while others encourage it.
The argument against remote workers usually is that it hurts company culture when some people are not in the office day to dayThis argument is more a reflection of the company not doing enough to support and include remote workers. By utilizing the strategies outlined in this article, companies can create an environment open to remote workers that does not have a negative impact on culture.

Our feeling is that if you get the work done, it shouldn’t matter where you do it. If someone is twice as effective at home than in the office, doesn’t it make more sense to let them work at home? What if the most talented engineer lives in Romania? Don’t limit your team’s potential because there are challenges.
 Building a company culture where remote workers are welcomed will not only make your company a better place to work, it will also affect the type of people who want to work for your company.

Hopefully, this article helps your team understand the challenges of having remote workers and gives you some good strategies for how to support them.

What should go into your MVP (Minimum Viable Product)?

Everyone’s company is different. So how should you approach building your MVP?

If you hang around enough startup folks long enough, you’re bound to hear the acronym MVP thrown around. While the quality of your team does matter, it actually has nothing to do with individuals. Instead, it stands for minimum viable product.

Eric Ries made the phrase famous in his book called The Lean Startup. Ever since Ries’ book, the startup world has run with the idea. But despite many people using the phrase, it’s interpreted in many different ways.

The part that causes the most discrepancies is the viable part. Viable is a vague term and can mean something different to each company. For example, what might be viable for a mobile app is not viable for a software product that helps launch rockets into space.

The way we like to approach building MVPs is by asking the question: what is the smallest product (or the least amount of features needed) that you could make that still tests your company’s key assumptions? This question still gets at the core of what a MVP is all about but the focus now is your company’s specific needs.

Every early-staged company has some key assumptions they are making. That’s what it means to be a startup. You started with an idea but before you put anything out into the real world, all that idea is is a hypothesis. And like any good scientist, you need to test your hypothesis. Therefore, before you code anything, you need to think about what your key assumptions are and build your MVP around testing those assumptions.

And that’s it. Your key assumptions are all you should be testing when you first start out. Once you get a better sense of whether your assumptions were accurate or not, then you can keep  expanding your product, testing more assumptions as you go.

The important point is to focus your MVP around what’s specific to your product. What will make or break it? That’s what you should be building to test. Everything else in your grand plan can wait because if you’re off in your key assumptions, nothing else will matter.

So before you dive into the code on your MVP, take the time to consider what it is that should even go into it.