The document summarizes Heek's product development process, which includes defining the problem, crafting personas, building prototypes, conducting private and public betas, and launching the product. Some key steps are identifying a problem by interviewing potential users, defining the "why, how, what" to clarify goals, creating personas to represent target users, iteratively prototyping based on user feedback, launching a minimum viable product, and using tools like Product Hunt to generate interest during public launch. The process aims to continuously validate assumptions and refine the product based on real-world user testing.

1. THE
PRODUCT
CYCLE

2. Your Living
Website
What’s Heek? Read our manifesto

3. The Heek Product Cycle
This 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.

4. Subject
selection
Identify a
big problem
Find a
Solution
Validate
concept
Meet people in
that domain
Prototype
Iterations
MVP
Private beta
Iterations
Public beta
Launch
The Heek Product Cycle

5. 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.

6. WHY
HOW
WHAT
And why it’s crucial

7. 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.

8. 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.

9. 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.

10. 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.

11. 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.

12. Crafting a prototype
with personas

13. 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.
Caution
Targeting 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!

14. 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)

15. 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.

16. 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.
Caution
Once 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)
NodeJS
MongoDB
Amazon Web Services

17. 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

18. Building the product with our future clients
The steps we followed

19. 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.

20. 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.

21. 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 MVP
A 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.

22. 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.

23. The public beta
Testing 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 what
Intercom : to chat with beta-
testers
Mixpanel : to track events
and create success funnels
Hotjar : to create videos of
user sessions

24. 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

25. Are we ready to launch?

26. Are we ready to launch?
Mmmm No!

27. Are we ready to launch?
Mmmm No!
Perfect, let’s launch!

28. 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!

29. 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.

30. 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.

31. 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.

32. 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.