Seleccionar página
Back in November we slogo-6780bb8e6725e305cb28224811f5fc81at down with Tony Cappeart, COO and Co-Founder at Contactually to talk about how they are applying Lean Startup methodologies to build their business. We talked about how Lean Startup had guided their product design, market segmenting and customer development. Contactually just announced the launch of version 2.0 of the product so we decided to check back in with them and see how things are going. Here’s what Brian Pesin had to share with us on how Lean Startup is informing the business as they step from version 1.0 to 2.0.

How did you determine what features to build into 2.0? 

We spent a lot of time talking to our users and potential customers to understand the pain points they were trying to solve by using Contactually. They also told us about how they worked and the tools they used to accomplish their goals, which gave us a few key narratives on which we focused in order to come up with new product ideas. In general, we heard that we were great at telling them who to talk to and when, but they still had a hard time figuring out what to say in order to stay top of mind and relevant.

Additionally, our customers were successful when it came to following up with individual contacts, but they wanted to engage more people meaningfully and at scale. At that point, we’d already partnered with ActiveCampaign, MailChimp and a few others, but there was still a gap when it came to personally engaging multiple people at once.

Brian Pesin

Brian Pesin- Marketing Manager at Contactually

What were your biggest surprises in usage for version 1.0 (were there features used more or less than you expected)?

We were really surprised at the amount of time that people spent on Contactually.com. Initially, we focused on having users come in and spend a few minutes sending follow-ups before going out the rest of their day. However, users kept returning to interact with their rich contact data, so we realized the importance of having a powerful contact database, especially given the lack of a great solution at the time. This led us to spend a lot of time developing our new search engine.

Why did you decide to do a full 2.0 release instead of smaller, iterative releases?

We normally iterate quickly, pushing new product features or small changes several times a day. However, the 2.0 features ended up being larger and more interconnected. We actually had a group of about 150 beta testers that got to use the features before we released it to the general public, and they often saw multiple product changes throughout a given day. The timing ended up coming together in one concise narrative.

Did you speak to customers about the 2.0 features and if so, how?

Definitely! We log every piece of feedback and every product suggestion we got, whether from an interview, phone call, support ticket, live chat and beyond, internally. We see what repeatedly comes up in conversations and use that as a basis. We also engage our top users to understand how they work and the features they need to achieve their goals.

What tests did you run to determine the features for 2.0?

We spent a lot of time creating wireframes for the new features before reviewing them internally and with a few of our power users. Then, once we built the initial feature, we shared it with our beta testing group to get their feedback.

How was developing 2.0 different from 1.0?

For 2.0, we had to build and develop for scale. In the early days, it was fine for us to build features that didn’t scale well. However, now that we’re supporting tens of thousands of users and their data, we have to keep completely different things in mind. For example, our previous search engine lived on a single server. We now have five servers running continuously.