Text

Stop thinking that internet marketing should come after building the product.

http://andrewdumont.me/build-it-but-they-wont-come

Cynical, but there’s no better way to put it. Building a product is only the first step of a very long journey, a journey that doesn’t always reward the best. In theory, we like to believe that if you matched up two products with identical functionality, the better of the two would win. Key words, “in theory.” I was reminded of this concept earlier today after a tweet from Dave McClure on the emphasis of product over marketing. twitter-twee…

I just’d like to pick up on that. Actually, this shouldn’t be “the first step”.

I totally aggree with the rest of the post and with Dave McLure when he says that

But not on this specific sentence : ”Building a product is only the first step of a very long journey”.

Actually, all the methodologies Dave McLure is selling to the world go angainst this way of thinking. Lean Startup, and more generally Lean Product/Business Development asks you to be rigorous on this : you need to build your customer acquisition channels AND your products at the same time, at least during the discovery phase.

The reasons are obvious. When building a product from the ground, you absolutely can’t know for sure your customers and your acquisition channels. You need to build those channels and discover them along your product. Each part feeds the other until market fit, and beyond.

And why shouldn’t I let the conclusion to Marty Cagan, who explains this way better than me!

http://www.svproduct.com/regaining-your-product-mojo/


Design In Customer Acquisition.  Especially for those of you doing consumer Internet products, you simply must worry about customer acquisition from the start.  It used to be that we said that the product team did the product, and marketing was responsible for customer acquisition.  Not anymore.  Customer acquisition is too critical, too expensive, and too integrated into the product (or needs to be) to be left completely to others.

So yes, you can’t be awesome without internet marketing, because it’s part of the discovery, but you can’t be awesome neither by thinking that internet marketing should come after the “first step” that is building the product.

Customer AND Product Discovery

Text

Where are my Hypotheses Eric?

I have a problem with the “Build Measure Learn” Lean Startup Wheel.

I really do. This Build Measure Learn thing let entrepreneurs and product managers think that the exploration process starts with the build phase. Which is damn wrong. And i’ll explain why.

Look at few years back, the Lean Startup wheel looked a lot like the Deming wheel (Plan>DO>Check>Act) : 

imageimage

Look at what it is now :

image

I understand the importance of marketing in the movement, and I’m the first one supporting it. It’s pretty cool to see more and more teams and startups trying to apply the Lean Startup principles. It’s good for the ecosystem, and it’s also good for the people working in those teams (but it’s another article I guess). And seriously thank you Eric to be the head of this. 

But still, I have a problem. I loved the first version of the wheel you showed to the world few years back. 

It was clearly explaining that there were ideas, and that those ideas were hypotheses. And that you needed to check them fast. 

I encounter more and more people forgetting that everything you do are hypotheses, and building a product doesn’t start by building the product. Build is an awesome word, but simultaneously a dangerous word. 

The dangerous part is not understanding that “build” actually means “do an hypothesis, plan how you’re going to (in)validate it and how you’re going to measure it’s success, and do it”. That is, for me, what is behind the Deming’s “plan”, and behind the old Lean Startup Wheel “Idea”. I’m going to repeat it, like a mantra for myself :  ”build” actually means “do an hypothesis, plan how you’re going to (in)validate it and how you’re going to measure it’s success and do it”.

And this is damn important. 

That is also why I’m building Experiments.IO. In this Lean Startup process manager tool, everything starts with hypotheses.  And that’s how it should always be.

Shout out if you liked the first version more!

Text

"Fake it ‘til you make it", or, as they say now "MVF, Minimum Viable Feature"

This is an absolutely necessary technique. I use it a lot.

What I think is important is to assert assumptions, a way or another. What is important, in an exploratory phase, is to do things in order to learn things. And the technique I love is the famous “Fake it ‘til you make it”, or, as they hypely say those days, “MVF” for Minimum Viable Feature.

Actually, to be more precise, it’s the first version of an “MVF”. But still, I love it.

I remember, on http://chooseyouboss.comI made an assumption : “I’m sure that candidates will answer faster if they had a responsiveness score associated”, so, on the mail I was sending them, and on their profile, I was just telling them : “your score is perfect, to keep it like that, always answer before 72hours”. That worked perfectly. KPI’s went up, and I didn’t even had to implement the feature. Even if sometimes, users ask me why it’s always ‘perfect score’ =)

So never forget, when you want to add something, always ask you this question : "How could I fake this, and still learn something valuable?".

Link

Of course, this is simple logic =)

This is the base of the Lean Manufacturing theory as per Toyota. 

Backlogs are also “stocks” (of stories).

The thing is, somebody needs to write those stories. Sometimes, they badly come with details (someone thought of!). Then, if you’re into scrum, bang, someone needs to evaluate it.

Then they’re here, hanging on the wall, waiting for someone to pick them up. But done stories change the whole story, like, let’s say, always. And then you need to change those stories. Sometime to remove those stories.

This is simple logic. Big backlogs, big waste.

Text

My definition of a Minimum Viable Product

For me, the definition of a Minimum Viable Product is simple. It answers yes to the three questions below.

  1. Does the product provides gain > pain to the customer ?
  2. Can the customer pay ?
  3. Is the product the sum of the minimal subset of features to accomplish 1 and 2?

The rest of the MVPs, like the (in)famous landing pages, or polls, or interviews, are more MTF (minimum testable feature) or MTP (minimum testable product), or what I love to call, an experiment.

Text

Awesome detail on google search

You can see a really great and simple advice when looking for a disease : “Please consult a doctor is you have a medical concern.”.

Text

Great Rails 4 Rake Task to Generate Rails Guides on Kindle

You should find your .mobi here =)

Enjoy!

Text

5 Tips I Use to Gain “Intense Focus” When I Code

Focus is the most important thing when you are coding. It allows you to achieve from end to end (idea > experimentation > measurement) little parts of your product efficiently. If you never manage to focus, you should not code.

By focused I mean :

  • driven 
  • efficient 
  • high achievements

As you’ll see, I’m not saying that I never read my emails or check my twitter. Just that by following and by compelling myself to the following tips, I manage to achieve features from end to end, tested, and deployed in less time than when I’m not in the following dispositions, for whatever reason.

  1. I am alone, or with someone never talking to me for at least 45 minutes.
    • This is really important. If someone interrupts me before, I have to regain focus all over again. And this is also the most complicated part. In a small structure, where I code and decide what to code with my collegue, we have always something to share.
  2. I know exactly what I want to achieve
    • I set the problem I want to solve, the solution/experimentation chosen, and how i’ll measure the success. This allow me to stay driven.
  3. I somehow know it will take me less than the day/2 days
    • Somehow means : by experience, “because I broke it enough into small pieces”.
  4. I compartmentalise the problems and anticipated solutions for each part
    • I Box each technical problem. Either by Stack Layer (async > fat models > controller > HTML/CSS/JS is the way I do it when using ror, xib > model > controller when using objective-c ) or any other way. It doesn’t matter. The important here is to take small problems one by one with the “big” picture in mind. Test Driven Development is insanely useful to achieve this. 
  5. When I feel the rush, I pause. If I detect a rush twice in the same hour, I head back home.
    • What I call the rush is when I’m starting to “tilt”. I’m speeding up, typing a lot of code, trying to “jump” from parts of the stack to another, trying to keep track of too many things in my mind “to remember” to change in the tests, well, breaking all the aforementioned rules =)

Hope this can help you. What are your tips to focus?

Text

More RSpec goodness

Some test refactoring led me to achieve some goodness with rspec.

We can definitely see here that the syntax sugar helped me write :

- more maintanable tests

- more readable results

- more understandable specs

Link