melissa perri

Why you should wait to pitch for money

Pitching for money too early can distract you from creating the best product. I know mine is sort of an unorthodox situation, but let me tell you a story:

When arrived at Techpeaks our goal for the first month was to form a team, come up with an idea, and then pitch for 25K euro.  We had one month to do this. Just remembering everyone’s name was a challenge, especially with 3 Riccardos and 4 Alessandros.

Having done Lean many times before, I thought this month would be plenty of time. My attitude was “I can validate anything in a weekend, no big deal.” And it’s true - you can validate a problem rather quickly. The hard part is creating a business that solves that problem.  

When you pitch to investors, they care about your business. How do you make money? How many people pay you money? We learned exactly what to put in pitch decks: problem, solution, business model, traction, team. If you look at these middle 3 parts of a pitch deck, you can see they take time. They take iteration to get right.

Pitching too soon doesn’t allow you the time to get traction and figure out what business model your customers respond to. In this early stage of a company, you should be creating or testing great product ideas. Pitching is a distraction. You can spend so much time saying “No that won’t work because we can’t make money” and pass on an opportunity to engage thousands, even millions of users.

After being together with my team less than a month, we created a pitch deck and got the 25K in the first shot, something not too common at Techpeaks. We had all the right materials: a strong problem, companies who agreed to test us, and a solid business model. After a month of creating tests and getting companies to agree to add us to their websites, we realized we were missing something: validation of our users. We spent a good amount of time before the pitch talking to one side of our market: the buyers. We needed this validation for pitching – it was the middle three parts of our slides. The response from them was really good, so we were encouraged to keep going. We received our funding and started building our MVP.

It wasn’t until a month later that we realized we neglected the most important part of our market: the users. These people were not the same as the ecommerce companies that would buy us. They had different problems. After interviewing tons of potential users, we found they did not have the problem we thought they did. We pivoted and found a different problem in the same area and we’re proceeding with that.

Techpeaks is unconventional to say the least. I know this can’t even be possible for most people, but if you think that you are far along enough to raise money, take a step back. Have you validated all parts of your idea? Do you have users? Are they coming back to your site often? Are you making money? If the answer is no, then this should be your focus. Don’t get distracted by money. Focus on your product, make sure users love it, and then find the money. Had we not been scrambling to make a presentation that sounded good to investors, we would have been validating and learning much earlier in our process. Just wait.

Support Systems

When I left New York for Italy, I thought of all the things that could be potential problems being so far from home. Could I buy the things I normally get here? How do I set up a new cell phone? What are the customs in Italy I should know before I get there?

One thing I really took for granted was the time difference between New York and Italy. It’s 6 hours. When my friends and I were discussing me leaving, we all said “Oh no big deal, it’s 6 months and we chat online all the time anyway.” It’s true, we’re a multitasking group who keeps in touch pretty easily through gchat. But now that we’re 6 hours apart, when my friends are just getting ready to chat after work, I’m about 2 hours into sleep. I wake up to pings on my facebook chat that say “hey!” left unanswered for 7 hours with no one on the other side when I awake. Pretty depressing way to wake up.

The friends problem sucks, but the worst is really not being able to talk to my mom. My mom is my biggest champion, my all ears, the person I rely on the most. I tell her everything from insignificant details to huge problems that I face and she talks me through it all. I call her everyday at home, sometimes multiple times, just to tell her about my day and see how hers is going. Now when I wake up, it’s 3 am her time, and when I go to sleep she is still at work. We connect every once in a while to chat for a little when she’s on lunch, but when she can actually take the time to talk after work, it’s 2am my time. Sometimes I get a skype call from her then, and I drowsily talk to her for an hour before I can’t keep my eyes open.

Don’t get me wrong. I appreciate the opportunities I have here, and I am really enjoying the experience (hopefully more upbeat posts soon!). But this has been the hardest part of moving to Italy, and it’s made me pretty homesick. It’s also helped me realize just how important it is to have a solid support system, full of people who care about you as much as you care about them. With all the technology we have in the world today, keeping in touch should be so simple. But so far there’s nothing that can fix time. Time’s a bitch.

My team got funded at Techpeaks!

I’m very excited to announce that my team, FlowsBy, was selected to receive the 25,000 euro funding from TechPeaks! We are tackling the problem of how to keep shoppers on your ecommerce site longer. My teammates include: 

Riccardo Osti is from Rome, and has founded 2 Italian startups before, Naroomi and He is skilled in sales, business development, and cooking awesome food.

Alessandro Marchesini is originally from Verona area, but spent the past 13 years traveling and working outside of Italy. He’s adept at sales and marketing, specializing in international markets. He also loves squirrels.

Giovanni Gaglione is our star programmer from Rome. His expertise lay in Big Data, Sentiment Analysis, and not hearing the alarm clock ring. 

If you’re wondering how the TechPeaks program works, let me explain for some background. Techpeaks is different from most accelerators because it’s a “people accelerator”. 68 of us were chosen from 40 different countries to travel to Italy and build companies. Most of us came as individuals. Once we arrived in Trento, we spent the first month mixing and mingling. We got to know each other, formed teams, broke teams, and came up with ideas of what to build. Once you have a team in place of 3-5 people, you can pitch to a panel of VCs and entrepreneurs who help Techpeaks select which teams get the grant. If you receive the 25,000 euro no equity grant, you can use it to build your company over the next 6 months.

So how did I get wrapped up with these three Italians? Well, you have to remember that Riccardo and Alessandro are excellent sales men – excellent. Picture this – it’s about 98 degrees in Trento. There is no air conditioning anywhere. When I walked out the door in the morning, I thought I was going to turn into a puddle right there on the street. After about 12 hours of dying in the heat, Ale asked if I wanted to escape the heat for dinner. HELLS YES I DO. So the three of them picked me up and whisked me away to Andalo, where it was a beautiful 70 degrees. We ate great food, chatted, and cooled down. They told me how they invalidated 3 of their previous ideas the day before by scheduling interviews and learning that their problems didn’t exist – the Lean in me was intrigued.

Then they told me about the ecommerce idea they had been thinking about. I was sold. I could see that this was a problem from my experience at OpenSky, and I thought it had great potential and presented an interesting UX challenge. We agreed to team up and flush out the idea more. 

Over the next week, we called 25 different ecommerce sites and validated the problem existed. They were itching for a solution, and most wanted to sign up for Beta right there and then. We didn’t pitch at the next Pitch Day because we wanted to start crafting our MVP first. So we did more validation and set up our test. Two weeks later we pitched for the 25K and received it on our first attempt. The judges said out of the 9 teams they had funded so far, we had the highest score.

Other teams that have been funded at Techpeaks include: CiceroosMemeoirsMapNautSparks, Rabid Fish, Genialis, and LearnPeaks.

I’m very excited to work with these guys, and am proud of how much we’ve accomplished over this short three weeks together. Within the next few days, we’ll be launching our MVP on a few websites to test our concepts and validate it. We’re committed to using lean methodologies to excel our business as fast as possible. If you’re interested in what we’re doing, I’m happy to chat and I can’t wait to post more information as our product evolves.


Why You Should Talk About Your Ideas

“Can you please help me figure out how to prove my idea with Lean?”

“Sure, what are you working on.”

“Oh, I can’t tell you. It’s confidential.”

I’ve had this conversation at least 10 times in the past year with an aspiring entrepreneur. They wanted advice and guidance on how to use lean with their idea, then refused to share what they were working on. One person wanted me to sign an NDA before we chatted… at a bar… at midnight. What?? 

People who do not talk about their ideas are at a sore disadvantage. Now I’m not talking about broadcasting your grand plan to a million people, but picking a few connections that you trust and respect can yield helpful advice and feedback.

I am currently validating an idea with my team here at Techpeaks. I’ve reached out to a few people back in NYC to receive their feedback and do a few interviews. Their insights have been inspiring and helpful.

Tim introduced me to the Jobs to Be Done framework and to help me align my idea around it.

Tohm shared his experience at his company and helped me think through the challenges and benefits of our current idea for selling to the potential customers.

Adam helped us streamline our goals and tests so we could focus on the technical feasibility of the project and not get bogged down by going too broad, too fast.

Jon and Pamela gave us a great way to test our idea very lean so we can begin starting experiments this week.

Some of my assumptions have been squashed. Some of them have been validated (so far!). It feels good to get the feedback, “Oh that’s a good idea”, but it’s been more helpful and constructive when people say, “Stop. The first part of that sounds interesting. The rest is crap. Focus on the beginning.” I find myself eagerly waiting for those moments to come up in the conversation.

So to those of you out there saying, “I can’t tell you what I’m working on, but it’s going to be awesome”… is it? Who is going to buy it? Have you asked your potential customers what they think? My advice to you is:

I’m overwhelmed by just how smart the people I know are. Thank you to everyone who has helped me, guided me, and have been truly interested in what I’m doing. I can’t wait to return the favor one day.

How to Get a Permesso di Soggiorno in Trento

  1. Get told at 12pm that you need to pick up papers and go to the office in North Trento before it closes at 3pm.
  2. Panic.
  3. Grab said papers and figure out how to get there. Look up bus route. Decide to take bus.
  4. Get talked out of bus decision by two friends who say that it’s faster if we bike.
  5. Agree to take said bike even though you haven’t ridden one in 10 years. Convince yourself that it will be a piece of cake.
  6. Get on bike. Panic.
  7. Wobble a lot and get scared of cars.
  8. After 10 minutes, acknowledge this was a terrible idea and you’ll never bike again.
  9. Follow one friend the wrong way onto a big ass hill. Say “Are you serious, we have to go up that thing?” Get laughed at.
  10. Get off bike and walk it up hill.
  11. Start to go down one way street as mercedes benzes start flying up the other way. Run into a few buildings. Straighten up. Finish down the hill.
  12. You start to feel a little sunburnt. Take your hand off the handlebars to check. Almost fall. Grab onto handle bars like your life depends on it… because it does.
  13. After 35 minutes of hell in 95 degree heat, end up on street somewhere near the office. Check google maps for address. Have google maps tell you it doesn’t exist.
  14. Ask a stranger for directions in Italian. Feel proud of yourself for not screwing up that many words. Find out the street has 2 names. Wonder who the fuck named the streets in Italy.
  15. Arrive at office. Get into elevator that more closely resembles a death trap.
  16. End up at front desk at 1:45pm. Find no one there. Go ask someone if they can help you. They say no and that everyone else is at lunch. Wonder if they are going to come back before 3pm.
  17. Someone finally shows up in office. Get a piece of paper and told you need to wait for the person to get back from lunch. Wander over to the vending machine. Admire all the flavors of croissants it carries.
  18. Get called into get your papers. Have lady look at your papers once and then not talk to you again. Sign your life away. Get your papers and realize they put your first name as your last name. Have her draw a diagram and tell you in Italian “well we’ll see if they accept it or not…”
  19. Bang head against wall.
  20. Figure out you need to mail these things somewhere else. Get confused because you were told this was a final document. Curse all of bureaucracy. 
  21. Wait for friends.
  22. Get back on bike and take different route.
  23. Route is completely flat and you get home in 15 minutes, quick enough to get a kebab and admire your sunburn. Figure you might give this bike thing a shot another time.

I promise to write things more relevant soon. I could have also title this “Why Melissa should not bike ever”

Arrivederci NYC… for now!

imageIn 3 days and about 5 hours, I decided to pack up my life and move to Trento, Italy for the next 6 months. It’s the most spontaneous thing I’ve ever done.

Surprisingly, I’m pretty calm about this. That makes me feel even more certain that it’s the right thing to do.

I’ll be participating in the new Techpeaks accelerator (, which brings people together from all over the world to create startups in Italy. The program really interested me because (in no particular order):

  1. It endorses and encourages lean methodologies. If you haven’t noticed by now, I’m a fan of that.
  2. It’s in Italy. I’ve been to Italy twice, and took Italian classes in college. I love the food, the culture, and of course, the wine. I never got a chance to practice my Italian skills, so I’m hoping to come back eloquently speaking the language of amore. I think learning different languages is important.
  3. I’m excited to work with people from all over the globe. Sometimes we New Yorkers get so wrapped up in our lives that we forget there are other cultures and other ways of living. We’re thought of as the “epicenter of the world”, whatever that means. The world’s a big place; I want to break out of my comfort zone, learn how other people work, and fully embrace new friends.
  4. I am ready to start learning and building. I learn from doing. I’ve always wanted to start my own company, and this is a perfect opportunity to work on something that I have been pondering for a while.

I’m approaching this as a learning experience. I don’t expect to come back with the next Facebook, but I think going through the program and meeting the people involved will be worth more than that. Hey, if we do come up with the next big thing, then that’s awesome. If not, at least I’ll have some great connections and I’ll be 50 pounds heavier (they appreciated that in Ancient Rome, just sayin’). I’m going to give it my all, but I’ve learned not to be crushed if your idea doesn’t work out. 

I will be documenting my journey on this blog. After some rallying from some fellow Techpeakers (whom I already like) Oscar is coming with me, and will be securing a EU pet passport. He will need some fancier sweaters if he wants to fit in with all the Italian dogs.

Ciao for now!


Lean Product Management on a DIME

While setting up my team to use Lean practices at OpenSky and Conductor, I had a hard time figuring out exactly what the role of a Product Manager was on the team. I knew that I was still in charge of the vision of the product, and thinking about where we would take it in the future. But, the main function of my job – coming up with what to build – was now something the whole team contributed to. Then there was the speccing, something that took up 80% of my day. Lean and Agile practice collaboration over documentation, so what happens to those documents I had been making? What exactly is a Lean Product Manager responsible for on a day to day basis?

I’ve found the daily role of Product Managers shifts away from churning out solutions and specs, and into that of a facilitator and team-leader. I became responsible for setting up the experiment, empowering the team to solve problems, and making the hard definitive calls, all while steering the vision of the product. In my class, I call this process DIME because it’s easy to remember:

Defining the Problem:

Product Managers bring the problem to the team and rally them around it. They are responsible for explaining why it is important to solve the problem, how customers are experiencing problems now, and what their potential solutions could mean for the company. When I have the original kickoff meeting with my developers, I try to tell them a good story about the problem. I get pretty dramatic for emphasis. (Thanks High School drama club.) The better story you tell, the more everyone gets excited about what you are going to build. Driving passion in the team to solve the problem is one of the most important jobs a PM can do.

Investigate Assumptions:

When we’re talking about the problem, I’ll use that meeting with my developers to talk about our assumptions. We’ll discuss how we believe the users interact with our product now, what we believe they do in their daily jobs, and other things we’re not sure about. After the team lists their assumptions on sticky notes, I’ll the charge to explore if these are correct or not. I always include my developers in this discovery process, so they hear first hand what the customer is saying. This makes them feel closer to the problem and gets them excited about coming up with the solution.

Measure Results:

Every problem that is getting solved should be tied to a KPI. The PM figures out what data to collect during the experiment, and then tracks it. I talk to the upper level management to figure out what are our business’s key goals for this feature. Do they want to see higher revenue? Do they want to increase engagement? What is it about this feature that will change our business as we know it today. Metrics can drive so much insight to help your decision making in a startup, but you’d be surprised how many companies have none implemented.

Evaluate Success:

Finally, I reflect on my feature experiments and decide whether it was successful or not. This can be a hard call to make. Sometimes the data is juuuust off the marks you wanted to hit. Sometimes everything is a complete flop and you’re not even sure where you went wrong. It’s up to the PM to lead the discussion with the team and make the ultimate call around the success of your project. If it failed, I’ll investigate the cause of the failure to determine the next move, usually by talking to customers. If it succeeded, I will drive the initiative to build out a full product (remember an MVP is only a test!)

When you work in small teams, everyone wears many hats. Sometimes it can seem a bit chaotic, and you’re not sure who is in charge of what on a daily basis. It’s important to have guidelines on who is in charge of certain aspects of the development cycle so they can lead the discussion around decisions and make the calls in time of dissent. Using DIME has helped me define my day to day job as a Product Manager in a Lean team, while keeping our teams balanced and focused on the vision.

Lean UX NYC Recap

When Will asked me to speak at Lean UX NYC on Lean Product Management, I was both excited and confused. It didn’t make sense. This was a UX design conference, what would he want with PMs?

When the first day of the conference was over, no one thought it was just a UX design conference. There were speakers on every section of the business. Johanna Kollman talked about how lean makes learning the new deliverable for design consultants. Adrian Howard explained that the lean process is actually brand discovery for startups. Bill Beard spoke on how copy should be integrated into Lean UX to enhance the user experience rather than be used as a crutch. Grace Ng showed how UX designers can leverage the concierge method to do Minimum Viable UX before designing the whole product. Tomer Sharon gave user research tips for engineers: “Watch what the user is doing, instead of asking the user what they need.”

Throughout this whole conference there was one major theme: collaboration. The reason lean is so powerful is that it incorporates the entire team in solution generation. There is no longer a product “owner”. Virginia Cagwin talked about how you need to break down the silos in typical enterprise businesses and form balanced teams to produce sexy ideas. This is a huge culture change that is very hard for waterfall companies to understand and adopt, but it can be done. Ari Font Llitos showed how they do this at IBM by creating these small teams, and then teaching them design thinking.

Now once we have those small, balanced teams, the question becomes what process do we follow? Jonathan Berger brought up great points about creating sustainable pace for designers when working with agile development teams. Designers have been asked to work at the fast paced tempo of developers’ sprint cycles, which leaves them feeling overwhelmed and disempowered. Lane Halley and Courtney Hemphill spoke about how they are practicing ways that can help solve this problem at Carbon 5. They practice short, weeklong sprints that run through the build-measure-learn loop. The whole team participates in discovery, building, and testing during the sprint, eliminating the need for extensive documentation and designs. I think what made this talk even more powerful was hearing Courtney, a developer, endorse the integration of LeanUX into the agile workflow.

Will Evans wrapped up the conference with a great talk on modeling leadership. What really resonated with me was his call for creating a shared language for new processes rather than trying to distort the language of older processes to fit a model they don’t belong to. Designers and developers are subject to using industry jargon that doesn’t make sense to people outside those roles. Being able to effectively communicate with team members aligns everyone around a common goal. I picked up ways to communicate through two workshops last weekend. Jacklyn Burgan’s workshop on “Sketch Before You Etch” taught me a way to generate ideas with my team through simple sketches, something everyone can relate to. Lane and Courtney’s workshop on “Conversation, Cadence, and Culture” simulated the conversations and language I should use when sketching and building with the team. I just started working with a much larger development team, and effective communication has been a challenge for us. I’ve already started integrating these techniques in our new project and I’m seeing great results in just a week.

By Saturday, everyone from doctors to developers had given a talk. In fact, we could all probably form our own lean startup and make kickass products without needing to fill any roles. I realized now why the name of the conference makes sense. That’s what UX is: User Experience. It’s all the pieces of the business working together to make a unique, compelling experience for the people who use your product.

This is the first conference I’ve attended where people are still talking about it a week later, which only goes to show you just how much useful information came out of it. I’m still pumped. I met so many wonderful people last weekend, and I’m still riding the high of it. Balanced Team brunch with the speakers was just icing on the cake the next day, and I can’t wait to do it again soon. Thank you Will, for including me in an epic weekend. 

If you did not go this year, make sure you check it out next year (it’s already posted). The sheer amount of knowledge you’ll walk away with is well worth the ticket price and will continue to help you for years. I’ll be there, mumbling my speech to myself and shoving macaroons in my face. You can find me by the cookie table.

Dispelling Myths About Lean Product Design

The more I talk about Lean Product Management and UX, the more skeptical people become. I like skepticism because it makes people start questioning ideas and reasons, which opens up a great dialogue. I have been trying to implement more lean practices at my new company. Some people are very excited about them, others are wary. I get it, change is scary, but it’s also wonderful sometimes. Here’s a few of the myths I hear and what I tell people.

Myth: MVPs are ugly

Fact: MVPs are as beautiful as you make them

I hear a lot of concern that Lean UX is lazy UX. People think implementing an MVP means just releasing a half-assed version 1 of your product. But MVPs do not have to be ugly or broken. In Jeff Gothelf’s Lean UX book, he suggests implementing a style guide for your site so when you create MVPs they fit in seamlessly to the site’s design. If you create an MVP that is drastically different than your current design, you are actually calling out that feature to the user as something “different”, which can skew your data by changing their behavior.

The most important thing to remember about an MVP is it is only a test. You still need to revisit it and build the feature after you prove that it’s worth the effort.

Myth: Lean stifles creativity

Fact: Building MVPs takes more creativity

Have you ever tried designing a great MVP? It’s fricken hard. MVPs are designed for learning. If you design wrong, you can destroy your experiment. It takes skill to be able to make a small feature set or completely separate UX element fit seamlessly into your product. You also need to have the discipline and will power to scale back on all the wonderful features you would like to design and implement, and just choose the most important one. When making an MVP, you are taking a single goal and designing around it to make a simple and effective test. Most of the time, simplicity is a lot harder to design for than complexity.

Myth: I just need to build the feature and they’ll use it, it’s too obvious for lean

Fact: Customers will only use something if it solves a problem

Lean is just plain common sense for product teams. Do you really want to spend thousands of dollars in salaries building a feature you don’t know customers will use? My team spent two sprints building a must-have feature involving organization. When I was talking to customers, I strategically beat around the bush to ask them if they had a need for it. They said no. In fact, they had no idea what I was talking about until I showed them the feature. When I pointed this out to others in our organization, they said “Well I know the customer said they don’t really care about that feature, but they’ll use it when we release it.” Will they? How can you be so sure? And do you want to take that expensive chance? When you start implementing lean, you talk to your customers early and often before building the feature. This doesn’t just help with justifying the resources, but also prioritization. In the same conversations, customers organically lamented about an edit feature they wish we had. We’re working on that feature now, but I would have prioritized it over the organization feature from the beginning.

Myth: Lean is rigid

Fact: Lean is quite flexible

When I explain lean processes, I get the response: “I usually don’t work with such a rigid process.” I’m shocked to hear this as often as I do, since that’s not the point of lean. Lean is a set of processes and guidelines that you should adapt to suit your company. It’s meant to work alongside agile development in the product space. People also get nervous about the minimum success criteria and data collection. They’re afraid to throw away an idea and miss out because the data is telling them it’s not worth it. If you come to that point where you think your idea is great and the data is telling you otherwise, the best thing to do is iterate. Try the experiment again and see if the data is matching up. You might find out there were external factors affecting your outcomes and it actually was a great idea! If you try it a few times and you’re getting the same results, it’s best to pivot using the feedback you collected. There is no set of rules that say you can’t iterate more than once.

3 Tools for Lean Product Managers

During my Skillshare class I cover a wide variety of topics on Lean Product Management to give my students a good overview. One topic we get into before the workshop section is Tools for Lean PMs. These are web tools for creating MVPs, measuring analytics, and watching user behavior.

Here my top 3 that Product Managers should consider using when running a Lean experiment. To get the full list and find out how to put then into practice, check out my Skillshare class. I know not everyone can use all these tools below, but there are many others out there to help you run lean. Feel free to ask me about them.

1. Emails

When I think of Lean, my mind automatically goes to Emails. Man, I love emails. I’ve been testing things leanly with them the past year. They’re cheap, easy to set up, and you get instant results. Amazing.

One of the projects I tested with emails at OpenSky was the implementation of a product review program. It took all of 2 days to put this in place before we spent a month building a full-fledged review program. I sent an email out to about 2000 buyers asking them if they would review the product they bought. When you clicked on the email, it took you to the existing product page and just scrolled down to the Facebook Comments section where they could enter the review (no coding done on the page at all). We proved implementing the feature was worthwhile as the percentage of comments we received doubled, showing customer interest and commitment.

If you’re an existing company, you’re probably already using MailChimp, Sailthru, or another client. You can easily recycle one of your templates to send out an email explaining a new feature or asking them to do a task. If you have a small subscriber list or are just starting out, check out Mailchimp. You can send up to 12,000 emails per month to 2,000 people absolutely free. They also have a bunch of premade templates, so no coding required. (And after you sign up and pay for your service, they send you a free t-shirt. Love my t-shirt. Good marketing Mailchimp!)

Once you send out that email, you can instantly gauge interest from your customers with clickthrough rates, opens, and conversions. All the clients track these things for you. Then you’ll be able to tell if your feature is a good idea or not in a day or two.

2. Optimizely

Optimizely provides a way to change the look of your website without a release of code. You can enter buttons to see if someone will click, change text, or implement a whole new section. It’s very versatile. For this one, if you want to get fancy you’re going to need some HTML and CSS. If you just want to edit text, rearrange things, etc you can use their editor without coding. So there is potential need for a developer if you don’t know HTML or CSS.

They do all the split testing for you, so you can AB test against your normal site at the same time. Optimizely also allows for multivariate tests to save time. You have total control over the length of test and the target audience. To get setup you just need to copy and paste their unique javascript on your HTML header. Then you can run projects within Optimizely. They do the analytical tracking for clicks and revenue, so you can see instantly what’s winning at the end of the test.

3. Crazy Egg

If you want insight into where your customers are spending time on your site, Crazy Egg is your tool. Their heatmaps will show you where your visitors are clicking and scrolling. If you’re planning on altering an existing page or testing a new UX, this is a great way to track if people are seeing your changes. This data is essential in making sure your customers are using the features on your site to the expected levels, and so you can iterate fast if they are not.

I found this particularly useful when trying to determine if our customers scrolled down to the end of the product pages. We had so many products for sale on one page, they could be scrolling down for a whole minute. Everyone was convinced we needed to change this layout because our customers would give up scrolling and not see half the products. There were long talks on how we could do this most effectively, but all the solutions were going to take a while to implement. So we popped Crazy Egg on the page, and found out about 80% of customers scrolled to the end. We were shocked and didn’t change anything.

There are a few downsides to CrazyEgg. It doesn’t work well on dynamic pages. If your info is changing from day to day, you can’t see where people are clicking and scrolling accurately. You can add it, but your results might not be that accurate. Also, you need some magic if you want to see clicks and tracking behind log in walls. Other than that, I think it’s a great tool to get customer insight.