Finding the Truth Behind MVPs

If you’re interested in learning more about MVPs, I’m running a one day workshop in Paris on June 14, 2016. More information here.

A Successful Start

I learned about Minimum Viable Products like 99% of other Product Managers – through The Lean Startup by Eric Ries. When I happened upon the book and Eric’s method, I thought, “YES! This is what I’ve been searching for. This makes so much sense.” Testing products before you build them? What a novel idea! I was excited. I was energized! I was now going to build things that mattered to my customers.

Frankly, this came at the perfect time for me. I was tired of building products that no one used. Watching and waiting for the numbers to go up in Google Analytics, only to be let down again. It was getting old. My team and I spent months building products we thought would be successful, only to be disappointed. When I had the chance to try the MVP approach on a new product, I jumped on it.

The CEO of our ecommerce company approached me with a new product idea that was going to increase engagement and sell more items. He wanted to implement a Twitter-like feed so that the celebrities, who sold products on our site, could also post about their lives. This idea was prime for testing. It was so ripe with assumptions: “Do our customers want to hear about what are celebrities are up to directly in our platform? Will this sell more items or increase retention?”

I went to the engineers and asked them how long it would take to fully implement this idea from scratch, the way our CEO was proposing. With rough estimates, I went back to our fearless leader and told him “This is going to cost us $75,000 to fully build, and we’re not even sure our customers want it. I can prove in a week with $2,000 if this is going to move the needle.” Just like that, I had buy in.

Within one week, we proved this was a terrible idea. A week after that we found a different solution that increased clickthrough rate threefold on our products. We also doubled conversion rate. The whole company was hooked, and we were allowed to keep experimenting. “Great,” I thought, “everyone can see the value of this! It’s a no brainer.”

Eventually, I moved on to another job. I was excited about bringing the concept of MVPs to this team as well. Honestly, I was kind of shocked that everyone in that company wasn’t using them already. Did they just not know about this wonderful witchcraft? I was so confident that everything would go exactly as it had in my previous company.

“We Don’t Do That Here”

When the words “Minimum Viable Product” left my mouth for the first time, the reaction in the room was quite different than I expected. You would have thought I recited every curse word in the English dictionary. Like I just busted out a Biggie Smalls song in the middle of the meeting, not bleeping out any of the colorful lines. They responded as if I had offended their ancestors. Finally the CMO broke the silence with, “We don’t do that here. We don’t ship terrible products.”

Over the next few years I experienced this same reaction countless times.

I’ve learned that Minimum Viable Products are widely misunderstood. Some people are afraid to try building MVPs because of preconceived notions. Others use the word so much that it’s lost all meaning. “We should MVP that!” has become a battle cry in product development that just means make it minimal, make it cheap, and make it fast.

How do people end up here? The story is almost always the same. Someone picked up The Lean Startup, had their mind blown, and said “We should do that here!” They saw a quick and cheap way to execute on a product without fully understanding what the purpose of an MVP was or how to make one well. In my particularly jaded company, a developer ended up creating a hack to test a new feature that broke every time someone went to use it. Customers were pissed. The company blamed it on MVPs as a whole, rather than sloppy development.

It’s not the MVP’s fault. The problems stem from misinterpretation of what an MVP is and from miscommunications along the way.

What is an MVP?

My definition of a Minimum Viable Product is the smallest amount of effort you can do to learn. When I teach this in workshops, I’m usually met with disagreement. “MVPs are the smallest feature set you can build and sell! Not just an experiment.”

So what is the truth? Is an MVP a product, a subset of a product, or just an experiment?

The Minimum Viable Product was first coined by Steve Blank and then made popular by Eric Ries in The Lean Startup. I went back to research how these two experts, and a few others, defined the term.

“The minimum viable product is that product which has just those features and no more that allows you to ship a product that early adopters see and, at least some of whom resonate with, pay you money for, and start to give you feedback on.” – Eric Ries, 2009

“Minimum feature set (“minimum viable product”) is a Customer Development tactic to reduce engineering waste and to get product in the hands of Earlyvangelists soonest.” – Steve Blank, 2010

“A minimum viable product (MVP) is not always a smaller/cheaper version of your final product.” – Steve Blank, 2013

“An MVP is not just a product with half of the features chopped out, or a way to get the product out the door a little earlier. In fact, the MVP doesn’t have to be a product at all. And it’s not something you build only once, and then consider the job done.” – Yevgeniy Brikman, Y Combinator, 2016

Confusing, yes? The one thing that was clear to me through this research is that the definition of an MVP has evolved. In the beginning, we talked about this concept as something to validate startup ideas. All these products were searching for product-market fit. I learned about the Concierge Experiment and Wizard of Oz in those days, which helped shape my definition and understanding. As I continued to use these methods as a Product Manager in enterprises and other more mature companies, I had to customize both my definition and the practice of building Minimum Viable Products. What I’ve learned is that you need both – the concept of experimenting and building a minimum feature set to be successful.

While there’s tons of dissent on the definition of an MVP, everyone pretty much agrees on the goal. The goal of an Minimum Viable Product is to rapidly learn what your customers want. You want to do this as quickly as possible so you can focus on building the right thing. So let’s get rid of the buzzword and focus on that premise. Let’s stop arguing about what an MVP is and start talking about what we need to learn as a company.

How and When to Learn

When we start off building a new feature or product, there are a million questions to answer. “Is this solving the customer’s problem? Does this problem really exist? What does the user expect to gain with the end result?” We have to find the answers to these questions before committing ourselves to building a solution.

This is why starting with a minimum feature set is dangerous. When you jump into building a version one of a new product or feature you forget to learn. Experimenting helps you discover your customer’s problems and the appropriate solutions for them by answering these questions. It also doesn’t end with just one experiment. You should have multiple follow-ups that keep answering questions. The more you answer before committing yourself to the final solution, the less uncertainty there is around whether users will want or use it.

Once you have proven that a user wants your product, it’s time to investigate a minimum feature set. Now we can start to find a product that is marketable and sellable, but also addresses the user’s needs that were uncovered through experimentation. Delivering this product to market as fast as possible is the ultimate goal, so you can get feedback from customers and iterate. But, you have to be careful to deliver a quality product, even if it’s tiny. Broken products do not produce value for your customers, only headaches. Any version of a product that does not deliver value is useless.

How does this look in practice? In one SAAS company I was working at, we had to create a new feature that would help our customers forecast their goals. We were given input by the customer’s sales team from their conversation with the customer. After reviewing the information, we knew we had to learn more.

We met with the customer to understand what they were looking for in this forecaster. Once we thought we had a good grasp of the needs, we built them a spreadsheet and dumped their current data into it. This took us less than a week. We presented the spreadsheet to the customer and let them use it for a week before getting their feedback. We didn’t get it right the first time, or the second, or the third. But, on the fourth iteration, we were able to deliver exactly the results the customer was looking for. We did the same process with a few other customers to make sure this scaled.

While the spreadsheet was providing immediate value to some of our customers, we didn’t have the resources to do it for all of them. So, we had to build a software solution. We started exploring the Minimum Feature Set, using the feedback we received on the spreadsheet. There were plenty of other bells and whistles the customers wanted, but we paired it back to the essentials in the first version. We spent a few weeks getting the first version to work and include the most important pieces. Then we turned it on for the clients with the spreadsheet to get their feedback. After iterating a few times, we began selling it to others.

This process is will help your company find problem-solution fit. If you are creating a new feature or a new business line that solves a different problem for your user, this method can help ensure you’re building the right thing for your customer. But what if you have a mature product and are not starting from scratch?

Experimenting in Enterprises

Many enterprises today are introduced to the Minimum Viable Product by consultancies who propose creating an entirely new product from scratch. This is may not be the best idea. When your company already has product-market fit, you have already built a product that customers are using. You do not need to rebuild your product, you need to improve it. The methods should to be adapted for this case.

Something that sets these two methods apart is the goal. When searching for product-market fit, you want the user to adopt and probably pay for your product. This is not always the goal when improving existing products. It could be to improve retention or increase engagement with certain parts of your product. Whatever you decide your goal is, it should be clear to the team and informing all their decisions.

Once the goal is clear, you again focus on learning. What do you need to learn before committing to a solution. Write out these hypotheses on what you think will move the needle, and then design a Product Experiment to test it. You don’t have to create an entirely new product. Maybe you will find out a new product is necessary while experimenting, but that should not be the end goal.

A company I coached wanted to increase their conversion rate across the site. They already had a popular ecommerce subscription product with thousands of users. Traffic was coming in, but users were not converting as much as projected. Nothing had moved the needle when it came to offer testing. They dug into the sources of where great customers were coming from and found that many came through referrals. But, only a few people were actually sending referrals. Through user research we discovered two main reasons why: they didn’t know they could actually send referrals, and they were not sure what the referral gave their friends.

The team decided to tackle the first problem with the hypothesis, “If we let users know clearly that they had referrals available, they would send them.” The first experiment involved showing a pop up that encouraged users to send referrals when they next logged in to the site. Referrals sends went up 30%, leading to an increase in conversion rate! They did not have to implement a whole new program here; they just had to create ways to make it visible.

This team continued to dive into problems around conversion. They learned that the top three problems on the direct-to-site experience were:

  1. Customers were not sure how the service worked.
  2. Customers wanted to know what specific items came in the subscription.
  3. Customers were not sure why the product was priced higher than competitors.

The next step to solving this problem was to see if they could deliver value and learn at the same time. They created the hypothesis, “If we give users the information they are searching for in the sign-up flow, they will convert more.”  They also wanted to learn which questions people would click on most to see which problem was the strongest. They planned a simple way to get people the information they needed while signing up: adding a few links into the sign-up flow, echoing the questions back to users. When the links were clicked, it showed a pop up  explaining the answer to the question. At the end of the week of building and testing, they could see the experiment increased conversion rate closer to our original goal. They also learned that showing the information about what exactly came in the subscription was the most important thing. The team continued to learn what was preventing prospects from signing up, and systematically answered those questions through experimentation.

Caution Ahead

One mistake companies make when dealing with Product Experiments is keeping them in play once you have learned. These features then break and cause problems for your users. You are designing to learn and move on, not to implement something that will last forever.

With the team above, they learned that the information they provided was helping prospects answer their questions, but not enough people were seeing that solution. After experimenting more, they learned that a more robust solution would be needed.

It was time to start planning a sustainable solution that incorporated the learning from the experiments. Moving away from Product Experiments to the next phase is not an excuse to stop measuring. This team was still releasing components in small batches, but those batches were complete with beautiful design and a more holistic vision. After every release, which happened biweekly, they would measure the effect it had on conversion and test it in front of customers. The feedback would help them iterate towards the product that would reach the conversion rate goal.

Chris Matts has eloquently named this the Minimum Viable Investment. He’s also pointed out that you should not only be looking at improving your user facing products, but the infrastructure that helps you create those products quickly. The team above is also improving their site architecture to experiment faster while waiting for test results. I introduced the Product Kata to teams improving their products to help them find structure through Product Experiments and Minimum Viable Investments.

Learning is the Goal

One of the scariest parts of this process for companies is releasing things that are not perfect. It’s important to balance good design with fast design and good development with fast development. The best way to do this is getting UI designers and developers to pair together. After defining what the goal is for the iteration or experiment, sit down together and talk through ideas on how to execute. If we design in a slightly different way, is it just as useful to the user, but easier to build? Prototype together. Sketch together. Work side by side and talk about trade offs the whole time. This is how good teams move quickly and avoid rework.

By learning what the user wanted early, I’ve avoided countless hours of rework and throwing out features all together. This is why it’s so important for teams to experiment, whether they are B2B or B2C. Give the product teams access to users. I’ve seen fear in companies that their employees will say or do things that will upset users. If you teach your product teams the right way to communicate and experiment, this will not happen. Train the teams in user research. Don’t release experiments to everyone. Create a Feedback Group with a subset of users. Build infrastructure so you can turn on experiments and features just for smaller group. These users will guide you to create features that will fit their needs.

I dream of a day when I can walk into a company and mention “MVP” and not hear, “We don’t do that here.” While the definition of Minimum Viable Product may work us into a tizzy, the goal behind it is extremely valuable for product companies. If you’re having trouble implementing these practices inside a company, try leaving out the buzzwords. Use terms like experimenting and focus on the premise. Learning what your users want before you build it is good product development. Make sure when you do invest in a feature or solution, it’s the right one.

This post was originally published on InfoQ on April 18, 2016.

Changing the Conversation about Product Management vs. UX

pm ux fight

If you had to pick one, would you rather be a Product Manager or UX Designer?

I’m both.

You can’t be both. We need to put you on the right team.

That’s not your job.

I had no idea what a Product Manager was when I started at Capital IQ, almost 10 years ago. I didn’t even apply for the job. A friend told me they were hiring, and I asked if there were any roles for people like me — engineers who liked Photoshop. After talking to a few people, I was told I’d make a good Business Analyst (their term for Product Manager, I’d later learn). The combination of business and analysis sounded intriguing, so I jumped on the offer.

My responsibilities were gathering business requirements, specifying features, passing the specs off to engineers, mocking up the interfaces in Photoshop, user acceptance testing, gathering feedback from customers, user research, and managing the scope. The company was far from Agile or Lean at the time, but I didn’t know any better. I loved it. Solving problems and watching them come to life was way better than my other options — supply chain management or coding.

Four years later at OpenSky, I heard the term “User Experience Designer” for the first time. My boss announced we were hiring a Director of UX. Apparently my role as a Product Manager was not the same as a UX Designer. What?! I was blindsided. The UX Director was now in charge of all the interface designs and mockups. He made it sound like a good thing. “Congrats! You don’t have to do any more wireframes.”

But I loved designing. I loved creating flows that solved problems.

The developers were finally participating in the process too. We were sketching together, incorporating each other’s ideas, and pairing on iterations. When the new Director of UX started, most of that went away. Now there were hand offs. I was still testing product ideas, but I didn’t get to participate in what that looked like for the user.

Quickly I realized this was not the role I wanted. I left to become the Lead UX Designer at another company. Now I had the opposite problem. I wasn’t allowed to participate in feature decisions. Those were made by the Product Managers. I was just the person who designed them. I felt like Lucy and Ethel in the chocolate factory, trying to wrap up all these features in pretty designs. The conveyor belt never stopped.

lucy and ethel

I wish product ideas were chocolate so I could eat them.

I saw features become approved that didn’t relate to the feedback I was hearing from customers. When I tried questioning why we were building them, I was quickly shot down. Once I brought up the idea of making an MVP. Wrong move. I got a few death stares and was told “We don’t do that here”.

I was confused. If I did both Product Management and UX, and I was good at doing both, where did I fit in?

There’s some UX in your PM.

When I compare these roles, I see responsibilities that are clear cut. For example, prioritizing feature requests has typically been led by a Product Manager.

Then, there are responsibilities that are murky. Who makes personas? At one company I’ve seen it as the PM, at another UX, and at another Marketing. Who owns User Research? Same story.

If you read different job descriptions, you’ll start to see a lot of overlap in major responsibilities:

 UX vs PM

When I was writing the Product Management curriculum for General Assembly, we had trouble here as well. There were weeks dedicated to topics some saw purely as UX — personas, research, wireframes, etc. But these are all necessary for Product Management too.

It’s not about roles, it’s about skills.

I’ve found the definition of roles matters less than how a company operates. Highly collaborative teams have Product Managers and UX Designers who assign each other tasks based off what they need for the project. Whoever is best suited in that moment to do it, does it. They agree on this. Sometimes the UX Designer might be doing research, other times the PM, and hopefully, more often than not, they’ll both work on it together. Everyone can move forward without feeling territorial.

Companies need to realize that both Product Managers and UX Designers are important, but what’s more important is that these two people can make decisions together. Product Management with no User Experience Design creates functional products that don’t make users excited. User Experience Design with no Product Management produces delightful products that don’t become businesses. If these two roles are not sharing responsibilities, then you will have a disconnect in both your team and product.

If we change the conversation to skill coverage instead of role definition, it becomes clearer. Do we have all the skills we need on this team to validate and execute a product idea? If we have a Product Manager who cannot wireframe, let’s hire a UX Designer. If we have a Product Manager who does UX Design, let’s hire a Visual Designer. If we truly want to iterate and get to market faster, we need to focus on limiting our team size. Having too many moving pieces only slows us down. Limit the scope of the work and make more teams rather than adding on roles or people to one.

My knowledge of UX Design makes me a better Product Manager and my knowledge of Product Management makes me a better UX Designer. It makes me better at creating products that delight users and solve their problems. There’s a lot of people like me out there. Find them. Hire them. Don’t make them choose.

Please Stop Misusing Buzzwords

Please. Please, just stop. Stop using buzzwords if you do not know the meaning. Somewhere in the past couple of years “agile”, “lean”, “mvp”, and “scrum” became the “it” thing in the tech world. Everyone wanted to be agile. Every manager wanted to say they use scrum. I’m a huge proponent for these methodologies and practices – look above it says lean all over my page. I think they can really turn companies around and produce great products when implemented and used correctly. But, I have seen a fundamental problem with a lot of teams and people who claim to be agile or lean: they have absolutely no idea what these words actually mean.

Here’s one example of the wrong use of a buzzword gone haywire. During August at Techpeaks, the staff announced they were implementing a “scrum of scrums” every Wednesday. Upon hearing this new plan, I asked myself “What the hell, is that even possible?” If you know what scrum is, you will understand that this term doesn’t even make sense. It got better when they explained that during this “scrum of scrums” we would have a mandatory 2 hour meeting with all 20 teams at Techpeaks where each team would stand up and say what they did last week, what they’re doing next week, and what problems they need help on. At this point, I audibly said “what the hell?” Obviously, this is just a progress meeting to keep track of what the teams are doing, but by using the term “scrum” a whole abyss of misunderstanding opened up. Teams started freaking out that the day for scrum didn’t match up with schedule for scrums that people were doing in their teams. Huge debates started about teams changing their scrum schedules to match the Wednesday end date, or move the Wednesday date to Friday so they can report on what they did. This discussion went on for weeks and weeks, and “scrum of scrums” (which ironically got shortened to “sos”) became a huge point of contention and anger for all the participants.

The misuse of one word, “scrum”, started a landslide of problems. Our common language started to unravel. One group was no longer on the same page as the other, and working relationships became utterly confusing. This is the danger of using buzzwords without understanding the meaning. The words become nothing more than a shiny badge of honor for being “cool” in this industry. Congrats, you are a lean startup and the new hip place to work. But what happens when you advertise this and attract people who actually know lean startup, and want to conduct lean experiments? They will be unhappy, because you will have promised them something different than what they understood. I know, it’s happened to me.

It’s imperative that we cut the crap with buzzwords and start using them properly. Simply launching a landing page does not necessarily make you “lean”. Deciding to chunk up a large project over 4 weeks does not necessarily make you “agile”. There are theories behind all these practices that were lost along the way. So here is my quick refresher on what these common buzzwords really mean and some common misconceptions:

Agile

Agile is a set of software development methods that focuses on iterating products incrementally. Agile values continuous delivery, personal interactions over documentation, and close collaboration between cross-functional teams to plan and evolve requirements and solutions. You can read the Agile Manifesto here and the 12 principles of Agile here.

One common misunderstanding I see is when developers require Product Managers to write out a complete, multipage, highly detailed spec before starting development on any products. The first half of the Agile manifesto states “Individuals and interactions over processes and tools. Working software over comprehensive documentation.“ Working face to face inside the team rather than handing off documentation not only creates a more collaborative environment, but it surfaces problems earlier.

Scrum

Scrum is an Agile framework that embodies the Agile manifesto in its practice. Scrum contains 3 core roles: the Product Owner, the Scrum Master, and the development team. Work is defined and agreed upon by the team and then sectioned off into sprints of a certain length. Scrum values teams working together to complete a common goal, responding to customer’s changing needs, and delivering quickly. You can read more about Scrum practices and values here.

Scrum is not a rigid process, but many teams understand it to be. One very common statement I hear from teams practicing scrum is that once the sprint is planned, nothing can be changed. This directly contradicts the flexible nature of scrum and one of the principles of Agile: “Welcome changing requirements, even late in development.“ This is not to say that you should be changing what you’re building all the time, but learning to be open to changes in product backlogs and deciding if they are a bigger priority is key.

Lean

Lean is most commonly used in our industry referring to Lean Startup principles, but Lean originated from the Toyota Production System and the term is also used for Lean Software Development. Using the term just “lean” can get really confusing depending on who you are talking to. For our sake, we’ll stick with Lean Startup Methodology when we refer to Lean here. Lean Startup Methodology focuses on building what customers will use, not what you think they will use. It values eliminating waste, maximizing learning, and measuring results. Iterating through the Build-Measure-Learn loop quickly is the goal.

Many folks miss the maximizing learning part of Lean. They build products quickly, release them to customers, and ask them if they like it. As soon as they get a yes or see a bit of traction, they think they are done. They stop talking to customers, and just keep building. Soon customers are out of the feedback loop. If you are focusing more on building your solution than learning from your customers, you are not Lean.

MVP

“Minimum Viable Product” is the least amount of work you can do to learn from your customers. MVPs are experiments, not minimum feature sets. In fact, an MVP can be manually delivered without a website at all. The main goal of an MVP is to learn if customers have the problem you assume and want your solution.

Many people think an MVP is just the minimum website they can create for their product, most often a landing page. While a landing page is a good tool to gauge customer interest, every MVP is not a landing page. A landing page is just one piece of the experiment. Targeting the right subset of users, driving traffic to the page, and delivering results is the entire MVP.

One day, these buzzwords will die down and others will emerge. This whole cycle will start again – learn, practice, fad, misunderstanding. It’s always a good move to educate ourselves and others on new trends, to make sure we understand the deeper meaning behind these words and keep a common language in our workplaces.

Lines Not Dots

When you first meet someone interesting, you usually start slow, talking about yourselves and getting to know each other. We don’t normally start discussing how awesome we are, and hit someone up for a favor… unless you’re an asshole. So why do we do that with investors?

This past week I was at Web Summit in Dublin. There were 10,000 people there. 600 startups (one of them was FlowsBy). Very very few investors. So when the startuppers did see a purple investor badge, they panicked and started running after them. I watched as Dave McClure got off the stage, and was immediately pounced upon by at least 30 people. They were shoving papers in his face, wildly trying to put a business card in his pocket, and pretty much screaming pitches at him. It was like a scene from animal planet. Dave looked like he wanted to be anywhere else but there.

I’m not an expert, but I’m pretty sure you don’t want the person you are trying to get money from to feel like they have to run away from you as soon as they meet you.

The last night at Web Summit, I actually ran into Dave at a small party. Well more like he kind of fell backwards into me and we started talking. We chatted about the conference and random things. I told him I saw the gang of people descend on him when he left the stage. When I asked if that pretty much came with the territory, he sighed and said “Yeah… but I have no patience for that at all.”

As startuppers, we tend to think of investors as “higher beings”. They can make us successful, or make us fail. We give them hero status, look at them in awe, and by doing this, forget that they are actually human beings who need to be treated like so. We need to start having normal conversations with them, and stop asking for things right off the bat.

One of our first presentations at Techpeaks was from Evan Nisselson. He quoted a line from a post by Mark Suster on investing:

Investors invest in lines, not dots. – Mark Suster

Evan’s advice was to talk to people, get to know them, and build a relationship before asking for something in return. In this way, you’ll be remembered AND you’ll also get to know the person. I don’t think any of us want to do business with someone we don’t know, or with whom we can’t have a normal conversation.

There were tons of awesome people at that party – Robert Scoble, Elon Musk, CEOs, Investors, Founders. I got the chance to talk to all of them for hours (yeah even Elon!), but I never pitched anyone. When we talked about what we did I would tell them about FlowsBy. Some people wanted to hear more so we chatted and I received some great advice and feedback. But no one was there to hear me pitch. They weren’t there to hear anyone pitch. They were there to have fun, relax, and party their asses off. And we did. Until 6am.

The next time we run into each other, I’ll ask them how they are doing, and how’s life. There’s a better chance they will remember the person they had great time talking to and partying with at the only place open in Dublin that one night than the hundreds of people who pitched them at Web Summit as they passed by. That’s because we started to form a relationship. We took the time to get to know each other, even for a few minutes or hours.

So I challenge all startuppers out there, to fight the urge to pitch to every investor you just meet. You have to actively work to build relationships with people. Relationships last, even when companies don’t.

5 Observations About European Startups

For the past 5 months, I’ve been living in Italy starting my company, FlowsBy, at the Techpeaks Accelerator. I’ve had the chance to work with some amazing people from 19 different countries, right here in Trento. During August, I also had the chance to visit iCatapult’s accelerator in Hungary to speak to their new class of startups.

There was no end to the shock when I told people I was going to start a company in Italy. “So you’re leaving the second biggest startup hub in the US to go to the middle of nowhere Italy to build a company. Makes sense…” “Does anybody even work in Italy?” There was also lots of encouragement, but I also think those people saw this as more of a sweet 6 months “working” vacation and told me to have fun and “YOLO”. Not quite what’s been happening.

For me, a major reason I chose to come here was to get out of my comfort zone. We are incredibly innovative in the US, we have lots of things going for us. But, at a certain point you forgot there is anything else in the world but the US. I got very wrapped up in my own way of living and working, and I got complacent. I hate being complacent. It doesn’t force you to work harder. It doesn’t force you to be creative. So I came here not only to work, but also to learn how other countries work and think and live.

After 5 months, a few things have stood out to me about the startup community in the countries I’ve been familiar with here. Most of this relates to Italy and southern Europe, since that is what I know best. None of this relates to Germany, Switzerland, Austria or any countries up near Sweden, Finland, etc since I haven’t had the pleasure of meeting them yet. 

Europeans are great problem solvers

When I was in Hungary at the iCatapult accelerator, one of the participants asked Zoli Piroska, a question.

“What’s the difference between entrepreneurs in Hungary and entrepreneurs in the US?”

Zoli’s answer hit it on the head for me. He responded that Hungarians are great problem solvers, but Americans were great executors. I’ve also seen this in Italy and other countries as well. Europeans are used to dealing with terrible bureaucracy, people not wanting to do their jobs, and everything being closed on Sunday (this still gets my goat). They have been problem solving their entire lives. Every time I got a bit stressed out from some bureaucratic BS at Techpeaks, my cofounders from Rome would be calm as ever. “Don’t worry, we’ll take care of it.” As mafia as that statement sounds, that’s what Europeans do. They work around the problems with a calm and grace we don’t have in the US. We’re used to things working, and when they don’t we get stressed out or pissed off. Europeans on the other hand, are used to almost nothing working, so they’re immediate reaction is to go into problem solving mode. This is a wonderful trait to have in cofounders, and I’m really lucky that both of mine have it.

On the other side of Zoli’s statement, he said Americans are better executors. I have to agree with this. In the US, we have the motto of “get shit done”. We’re incredibly efficient so that we can get more done in less time, and we know how to prioritize. I’ve seen quite a few startuppers here get hung up on things that just don’t need to be done now, or are a lower priority. Some of this is just lack of experience, and some of it is the environment they live in. I was standing in line at the grocery store the other day as the checkout lady slowly read every one of the 200 items in front of me and then commented on them to the purchasers. It was my own personal hell. Life tends to move at a slower pace in Europe, and it’s a wonderful pace if you want to relax, but it takes a toll on the work that European startuppers can get done. When the services you need to operate are closed, or people don’t care if it takes 3 weeks to get you a document, you are forced to move at that pace.

There is a different way of speaking

On the topic of inefficiency, one of the biggest challenges for me working with Italians has been learning their way of speaking. Not the Italian language, but the manner in which people speak. In Italian, there are a lot of pleasantries that are common practices. Some of these pleasantries don’t even exist in English, for example the formal “you”. For the others, we have similar ways of speaking in English, but most people would never talk like that. We prefer to get to the point quicker and be direct (without being an asshole). It’s something we’re taught in writing and speaking from an early age. Unfortunately, this can be seen as incredibly rude to any latin language speaker. I’ve run into this problem a few times here, which has made incredible strains on working relationships. Worried that I was being incredibly rude (because I know I can be short sometimes) I talked to people who worked regularly between the US and Europe. They experienced the same problems I have about the language differences, and told me I need to learn to adapt. So everytime I’m about to say something I normally would, I take a breath and really think about what I’m going to say. It’s hard. It’s not natural to me. I find it really inefficient to take 20 minutes to say something I could in 2 minutes. But it works and it’s something you have to do if you want to do business with people in latin speaking countries.

On my team, we’ve come up with our own working language. We all speak English, sometimes there’s Roman thrown in (and sometimes I understand it), and every once in while my cofounders will speak Italian and I’ll answer very slowly in Italian. But the most important thing is, after a lot of conversations, that we found a way of communication that we can all respect, knowing that we come from different backgrounds. That’s critical.

There are fewer women in startups than the US

One of the more disappointing things I’ve found about European startups is that there seems to be fewer women here than in the US. Out of the 65 people in Techpeaks, only 6 of us are female. That’s a damn low number. I’ve met a handful of other women cofounders around Europe. One I met at the Mind The Bridge Bootcamp, where she was pitching her first startup with another female cofounder. She is originally from the US and lived in Milan for the past 7 years. She asked me why I think there are not more women founders or women even working in startups. I’ve also heard this question from 2 really great women cofounders in Hungary. It’s a hard question to answer.

One of the reasons is that we don’t tell our young girls it’s a possibility for them. But, when you’re older and you’re thinking of entering the field, it’s not easy. I’ve heard it said “misogyny is a full time job” for developers in the US, but it’s doubly so here. I don’t think Europeans intend it with as much malice as some of the brogrammers in the US, but they’re not used to working with women. I’ve heard so many conversations here which would end up as an HR nightmare at home. Also, a lot of things that I’ve heard developers say at home in general about women, have been directed solely to me by peers here. It takes it to another level, that is incredibly uncomfortable.

One of the advantages we have in the states (which shocked the Hungarian founders) is that we have groups like New York Tech Women and Girl Develop It, that were driving initiatives to get more women into the field and also support them. That support would do women well here. In order to include more women in the startup world (which can help you be more successful) I think many European cultures need to first recognize this as a problem, then learn to be more open to women in the industry, and definitely women leaders.

The Startup camaraderie needs some help

One of the things I love most about working in NYC, is that I know there are so many people out there who support me and want to see my succeed. We go to events together regularly, we run into eachother at meetups, and we always ask “What are you working on? How can I help?” This camaraderie makes work enjoyable and motivating at home. I think this is what makes us a powerful nation for starting companies. That’s one thing I’ve seen missing from Italy. Silicon Valley got to where it is today because of the community. When I first visited San Francisco, the whole community was buzzing with startup events, meetups, and people who were doing interesting things. Everyone I talked to was willing to sit down to have a coffee with me, introduce me to someone, or invite me to an event. It’s a magnetic place, and if you are in startups, you finally feel like you’re home, surrounded by likeminded people.

Italy, and Trento, has a long way to go to get to this place. Bringing in startups and entrepreneurial people is a great way to get started, but a true community has not formed yet. One contentious debate we got into with a community of startuppers in this area was on Facebook. We had been asking people in “Startup Spritz” to help us out with sharing surveys, giving us feedback, and just telling them what we’re working on. Some of the members of the group (not everyone) went on a rant that they shouldn’t help us and we weren’t “contributing” to the community so we don’t have the right to post. Meanwhile, one of the Techpeaks requirements is that each one of us does 40 hours of work in the startup community to help leave some knowledge and work in Trento. So the reaction in the group shocked me, as we had talked to these people and exchanged ideas before.

I’ve always been of the mindset of pay it forward, and if someone asks me for help, I will help. Then, when I need their help at a future date, I don’t hesitate to ask for it. This mindset just isn’t dominant here yet. I was really happy to see after this incident a lot of Techpeakers felt the same as me. We help each other out, we don’t expect things in return. We know that we’re a community that will support each other, and that lets us thrive.

It is expensive to start a company here

I am certain that the entrepreneurs in Italy are doing everything they can to make their companies happen. To some extent, I think they are also more driven and passionate about what they’re doing than some people in the US. Why? Because it’s damn expensive to start a company here. You have to shell out so much money, jump through so many bureaucratic hoops to incorporate in Italy, that you better be passionate or crazy to start a company here. Let’s compare:

USA: In the US, you can incorporate in Delaware for $239. If you make no revenue, you pay no taxes. If you do not personally get a salary, you do not pay any taxes. So for these costs, you pay about $239 to start a company, and $225 to maintain your company while it’s not making money.

Italy: In Italy, you have to go to the notary public with lawyer’s documents to incorporate. The fee for the notary was €1700, the fee for the lawyer is about €1500. You also need to contribute share capital, which was just lowered from a minimum of €2500 to €0, thankfully. If your company makes no revenues every year, you have to pay a flat tax determined by the gov’t, which we believe will be around €4000. If you are a shareholder for a company, but you make €0 a year, you need to pay €4500 a year in taxes. So for these costs, you pay about €3200 to start a company, and €8500 a year to maintain your company while it’s not making money.

Many people who want to start a company in Italy, are asked to fork over their life savings to do it, so you better believe they are going to work their ass off to make it succeed.

 

I’m really happy I decided to come to Italy to work. Although it’s been nothing but a rocky ride, to say I’ve learned a lot would be an understatement. Entrepreneurs in Europe may be few and far between right now, but they are driven. The government and cultures make doing their jobs hard, and most of them want to come to the US where they can raise money and do good work. I hope that we reform a lot of our immigration laws so they can do just that.

For the US people reading this, don’t underestimate the European startuppers. I have met some really amazing, hard working people here. For the Europeans reading this, keep chugging, don’t be too proud to accept help, and learn about American culture if you want to go there. There is a budding startup community here, a few years behind the US, but give it some time and the right mix of people, I think we’ll see it grow.