THEPRODUCT CYCLE

Your Living Website

What’s Heek? Read our manifesto

The Heek Product CycleThis document is talking about the product cycle we used to create Heek. We’re just at the beginning of the adventure so it’ll be updated regularly.

Subject selection

Identify abig problem

Find a Solution

Validateconcept

Meet people in that domain

Prototype

Iterations

MVP

Private beta

Iterations

Public beta

Launch

The Heek Product Cycle

From the idea to the problem

SUBJECT SELECTION - We had an idea of the market where we would be good at, the website building market and online presence.

MEETING PEOPLE - We interviewed hundreds of people to find what they were struggling with: in the street, on the phone, through online surveys, at our office in Paris. We spent a lot of time doing it (and we still do). We had no clear questionnaire, just discussions, as open as possible so that people feel free to express their frustrations.

PROBLEM IDENTIFICATION - We identified that a specific target was struggling with a specific problem. And… OMG that problem was really big.

WHYHOWWHATAnd why it’s crucial

The Why / How / What…

It seems silly to a lot of people because when we brainstorm, we don’t produce. But trust us on that, you’ll produce a lot faster if your vision and how to achieve it is as clear as possible. Even if time and experience’ll shift it, or even if you’ll make a huge pivot, like we did.

This is basically a step that’ll transform an idea into a business, no pressure. If you start with the “what”, it’s a big mistake. It means that you thought about a product, which might be a good idea, but that’ll have no roots, no reason to exist other than the product itself.

Defining a good WHW is also a very good way to keep everyone in the team on the same page.

The Why / How / What…

Why are we doing what we do. In other words : What big problem will we be trying to solve? It takes time to address correctly, it takes time to phrase and rephrase. But once we get it, we stick to it, and every decisions we make seem logical because they are driven by a big picture.

Consider the problem you’re facing as a castle, if the problem’s not real, it’ll be a card castle, and every new idea, feature or team member you’ll add will be another card and will make it even more fragile, threatening to break it all.

If the problem you’re facing is real, it’ll be a solid rock castle, and every new idea, feature, or team member you’ll add will be a rock and will make it even more solid, up to the point that you’ll need to extend.

The Why / How / What…

How’ll we get there?

What is going to be the key advantage that will let us achieve our vision. How will our company fulfill our core belief?

In other word, what strategy will be driving us to achieve our vision. We still don’t talk about the product here.

The Why / How / What…

OK now we talk about the product. This is the easiest and least frustrating as we probably all started with a product idea. We tried really hard to get rid of the concepts and ideas of products we imagined through that process to get a fresh start.

The question we asked ourselves was simple : what is the product that would let us solve the big problem we are facing.

If the Why is real and the How is strong, the What will be logical. We don’t talk about the feature here, we keep it general, with a big picture.

Our Why / How / What

WHY - Helping Small Business Owners master the Internet when they lack resources

HOW - Creating the easiest and fastest solution to build a strong online presence

WHAT - Creating the first online presence builder assisted by artificial intelligence.

Crafting a prototype with personas

Defining our target market

Knowing more about the problem you solve, we also knew that not everyone had that problem. We defined our target market very specifically and tryied really hard to keep it as objective as possible. Even if we really want to deliver the best product to the entire world.

CautionTargeting everyone means targeting no-one. Our target is specific, and our product is inline with that. It won’t be liked or used by everybody, and some people will get frustrated. We live with that!

Creating our personas

We are lucky to have a big market, but that market has a price : it’s competitive and spread. Creating our personas is even more crucial knowing that. We need to identify our future users, those around whom we’ll build the product, those people who’ll spend time with us debriefing, giving feedback, and those people whom we’ll simplify the daily life.

We chose to start with 10 real people. We made sure that those people could be available to give us time. It’s always better to craft a product around personas that are real, so that there’s no negotiation possible if people think your product sucks.

What’s a persona ?In user-centered design and marketing, personas are fictional characters created to represent the different user types that might use a site, brand, or product in a similar way. (Wikipedia)

Defining our future clients needs

Trying to build one product, cross fingers and think that it would be adopted by everybody is a mistake that we don’t want to make. It is important to understand that a product has a chance to be adopted only if it answers specific needs. A hostel director is looking for a booking feature when a florist tries to sell online. It wouldn’t be appropriate to push the booking feature on our product the same way for those two businesses.

Doing this job at an early stage gave us the opportunity to understand what our product will be made of.

Start organizing the tech architecture

What was the vision behind, and what did we need to achieve in terms of architecture, in terms of coding languages, in terms of structure. This step was important because it gave enough information to the dev team to start working on something concrete, start choosing the right technogologies and start designing the architecture.

Our target is clear, we knew that they already have habits, we know that they already use online services. Fine for us! We won’t have to develop them but just plug them to our framework. Knowing that helped us prioritize the API as the center of our project.

CautionOnce you write your first line of code, your decisions become emotional. So take all the objective decisions before you actually start coding, designing. Our tech stack:AngularJS 2 (a bomb)NodeJSMongoDBAmazon Web Services

Crafting a very first prototype

We all (ALL !) brainstormed on the product to create:- We read a lot and we listen to a lot of podcasts, you can find a list

here- We analyzed, summarized, grouped our personas problems and

habits- We created our own product guidelines : bot first design (we’ll

share them publicly in a few weeks)- We tried really hard not to be influenced by what already existed- We used Principle to imagine a very first animated prototype that we

could show our personas

Building the product with our future clientsThe steps we followed

Iterating around a first prototype

We asked our personas to give us some time, by coming to the office, or by organizing a live chat.

Then we would try the product, show them each page of the process, and ask them where they are, what they think, what they like / dislike, and what they expect to happen on the next step.

We kept track of all their feedbacks, and summarize them.

Iterate around a second prototype

We iterated and designed a new version of the prototype with our personas feedback.

We programmed a second session of testing, adjust and make new assumptions. Then do the same process again.

The minimum viable product

One of the big product management duty is to keep everyone aligned on the same objectives. We don’t need yet:

- The best design- All the features- The best infrastructure

But we need to know where we aim to go. And with that information, we need to segment what’s really important to test our assumptions, and what’s not. Everything that’s not crucial shouldn’t be in the MVP.

We organize several meetings every week to keep being focused on the objectives and manage the priorities.

What’s a MVPA minimum viable product is a methodology created by Eric Ries (Lean Startup) has just those core features that allow the product to be deployed, and no more.

The private beta : how to iterate vertically

We have a MVP with almost the complete loop. That version is simple, but has all the most important features to verify our assumptions.

Our approach is vertical, so we have a vertical approach to iteration too. We select the target market along with our product roadmap.

We selected a few business verticals to assess our product and iterate around our MVP.

Why a private beta?We need to spend a lot of time talking to people and testing with them the different iterations. Qualitative feedback is much more important than quantitative so we need to limit the access to the people doing the jobs we address.

The public betaTesting in real conditions with traffic

In the beginning of August, we opened the beta to everyone. What’s the difference with the private beta?

- The subscription is free and open- Analytics are plugged so we can create funnels and

identify friction points- Hotjar to create a video of each session, and see

exactly what’s going on when there’s a friction point

The tools we use, for whatIntercom : to chat with beta-testers Mixpanel : to track events and create success funnelsHotjar : to create videos of user sessions

How we generated the traffic we needed for the beta

1. We simply subscribed on betalist.com, and were pretty lucky. Heek was in first position on the newsletter. Then in first position on the website, then was marked as trending for a weekend. The whole experience brought us around 1000 users (of which many sessions still need to be analyzed).

2. We also subscribed to some other beta listing websites, which had way less impact, but still…

3. We shared the news on the social networks throught the company profile & also throught our personal ones

4. We invited all the private beta testers to come back and try it in real conditions

Are we ready to launch?

Are we ready to launch?Mmmm No!

Are we ready to launch?Mmmm No!

Perfect, let’s launch!

The launch

We were getting ready to launch, even if we were not ready to!

We actually postponed the launch by 1 week because the incremental week was going to have a huge result on the user experience.

But we could have postponed it forever. It’s a trap we must not fall into, we decided to go, even if we still have 1.000 things to do, and even if we did not consider the product to be properly finished.

IT WILL NEVER BE!

The launch

We launched on Product Hunt to get the vibe...And PH was a big deal : thousands of visitors, most of them are techies, product or UX guys : they give feedback which is priceless! Product Hunt is a strong community, and in every community you must respect the rules.

Our launch on PH was a huge success, a lot of people gave tremendous feedback. And we realized at that time that Heek was going to be received positively by the market, and that the time to market was perfect.

The launch

TechCrunch also brought thousands of visitors more spread through the week, the pic actually came the day after the post was published.

There is clearly a before, and an after TechCrunch.After, you see tens of big medias talking about you, even though you never had any contact with them. The PR runs itself.

The launch

We then had a lot of different medias and visitors coming from the entire world : South Africa, China, Pakistan, Spain, Germany, England…

Hundreds of very strong backlinks, and not a single negative feedback.

This document is updated regularly along our adventure…

If you’d like to know more about the project, drop us a line at hello@heek.com.