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.