dailytraks – a mini-product from scratch – #4, idea pruning and validation

This mini-series focuses on ad-hoc quick-and-dirty product development, building a mini-product from scratch.

In my previous posts I’ve summarily talked about the product idea generation processproduct naming strategies and customer profiling and it was fun.

After sketching out the idea and pinning down the prospective customers it’s time to validate and polish the idea.

This phase is essential and skipping it is usually the biggest mistake a value builder does (that’s what we are right? call it whatever you want but in the end we create products and products add value).

Why is skipping validation and polishing your product definition a mistake? Well, think about it.

You have a product idea and:

  • you make assumptions about the benefits that your hypothetical product brings to your hypothetical customers
  • you skim down and think about these hypotheses, you expand them and give them veridicity
  • you plan how you are going to build the product based on this line of though, maybe invest in different things, you incur costs
  • you try to market it and… it doesn’t work
  • you scrap it

That happens because people don’t exactly behave like you want them to, or think about things like you do. We’re different and sometimes that’s not a good thing.

Validating

To work smart and build something that has the most important property of a product – a customer – you have to get out of your comfort zone and validate your idea.

That usually involves finding some people that fit your prospective customer profile and ask them a few questions, like:

  • have you ever encountered “insert the problem that your product solves”?
  • what do you usually use to solve “insert insert the problem that your product solves”?
  • how does that work for you? how would you do it differently?
  • would you use something that “insert product idea here”?
  • would you find “insert product benefit here” compelling?
  • what would it take for you to switch from “the product that you are already using” to “another product that solves the same problem”?
  • what would you pay for something that solves “insert insert the problem that your product solves”?

It’s very important to ask open-ended questions so try to avoid asking questions such as “is this something that you would pay for?” instead ask “how much would you be willing to pay for something that solves the problem?”.

If they wouldn’t pay for it (the pain is less than the gain) they’ll say nothing and you have your answer. If they say “I’d pay x $” you get more than a simple “yes”.

Polishing and pruning your product idea

While validating your product idea and talking with prospective customers you can also fine-tune it, polish it. If you’re taking the time to discuss with different people about your idea anyway why not shoot two rabbits with one stone.

Pruning (there’s a nice agricultural analogy for you) essentially means taking the details of your product idea and eliminating them one by one during validation.

It’s better to have 10 useful and complete features than 50 poorly thought and unfinished ones. Any product idea branches in 100 different directions. There’s a ton of things that your product could do, tens of problems it could solve. You don’t want that. You want a product that solves a problem really well in a simple and beautiful manner.

Plus, there’s this guy called Joseph Juran (a pretty smart guy) that suggested a principle and named it after another (pretty smart) guy called  Vilfredo Federico Damaso Pareto – the rule of “the vital few and trivial many”, or the 80/20 rule, or the Pareto principle.

scales_of_value

Now this little sucker is important and applying it will help you produce a better product with a higher yield. Now, if it doesn’t, it’s still going to lower your cost of failure, which is a good thing, however you look at it.

To apply it properly, think of the following axioms:

  • 80% of your results will be produced by 20% of the effort
  • 80% of the value of your product will be produced by 20% of your product idea
  • 80% of the problem will be solved by 20% of the features
  • 80% of your users will be satisfied by 20% of the hypothetical benefits

It’s not an exact science. For example, Microsoft Research found that the average user only uses 8% of Microsoft Word features. I don’t say that they made a mistake by developing 92% more stuff, but hey, if they could have stopped at 30% and only lost 20-30% of the userbase that would have been alot cheaper.

Now, applying this principle will help you determine which product features are important and you’ll be able to focus your attention and resources on these low-hanging, high-yield features, which will pay off. Identifying these takes a little skill and a lot of asking prospective customers.

That’s why it’s called pruning. You take your ideas, validate and polish them, and keep the most promising ones.

You don’t throw away the rest though. That would be dumb. Ideas are rare and easy to forget. Write them down and put them in an ice box. If your product is successful, you may implement them.

Back to dailytraks

Our little product is growing up and we’ve gone through the validation and polishing phase.

As this is an on-the-side, underground, “let’s tune our violin” product I didn’t go out harassing people with interviews like I’d do (along with some marketing types). What I did is this:

  • I set up a schedule and a budget – two weeks  duration, 4 hours effort
  • I contacted different people (a couple that I knew and 19 strangers – weird huh? like a stalker) and asked them my validation and polishing questions – out of these 21, I considered 17 to be relevant

I did this online, using slack (@startupstudygroup), LinkedIn and believe it or not, Facebook.

What did I find out? This:

  • It looks like having a sort of twitter variant that’s private and doesn’t have the 140 chars limit is really interesting. The problem that it solves is this: you collect your thoughts and any information you need to solve a problem or to investigate something in a topic – I’ll call that a trak. The most important thing, strangely enough, was the privacy – in this connected world it’s really nice to see that privacy for your thoughts is still a thing
  • having multiple traks is important – a user has multiple traks where he posts. each trak can be a subject, or a theme
  • usages:
    • as a log (as I tought – HA!)
    • as a medium to bring detail and clarity to ideas (4 actual persons said this – didn’t think about that)
    • as a place to write poetry (FREAKING poetry)
    • a more functional, simple notepad like app that i can keep to myself or share if i want (so private by design but shareable)
  • it should be damn simple by design, “to allow distraction-free creativity”, whatever that is. I’ll find out yet!
  • ideally it should have a web app AND a native app
  • it should include either text OR images. if it’s a text it’s plain text. if it’s an image it should be an image by itself
  • it should follow a timeline both in the web app and in the native app (HA!)
  • it should let you go through them either by searching, browsing through categories or visually – so actually finding them is important too :)

Also, most importantly, I discovered that something similar exists – https://thoughtstreams.io/ – similar as in it kind-off does something that is close, only publicly and, collaboratively, and multimedia and who knows what. It’s good to have some competition though, even if it’s not that close.

There you go. Now I have what it takes to take this idea to the next phase.

dailytraks – a mini-product from scratch – #3, who’s gonna use it and who’s gonna pay for it

This mini-series focuses on ad-hoc quick-and-dirty product development, building a mini-product from scratch.

In my previous posts I’ve summarily talked about the product idea generation process and product naming strategies and it was fun.

It’s now time to get into it and we’ll start with probably the most important product decision we’ll have to make – “who’s gonna use it and who’s gonna pay for it?”.

I know you have an idea and it’s the best idea ever – something catchy, that actually does something to help people and it rocks!  It’s yours, you love it, and you’re going to make it happen.

There’s something you need to think about though. The most important attribute of a product is not the idea, not the name, not the technology, or even the team. For “a product” to be a product it needs a customer, without a customer it’s just a thing you built.

Without a customer you’re just wasting your idea, your time, and most likely your money so you need to figure out who your customer is pretty fast, before doing a lot of work and spending a lot of money.

The difference between customers and users

What’s a customer? Somebody that is willing to pay you for something you have and that will give him something in return.

OK then, so what’s a user? Somebody that directly uses your product and gets first-hand value from it.

Why the difference? The customer may be your user. This is usually true. Emphasis on may be. The customer may not be your user. Think about a product aimed at children, like a toy. Who’s your customer? The mom right? And your user is the 4 year old getting all the kicks out of your toy. So the kid is getting first-hand value from your product and the customer benefits in some way from that value (emotionally or even some free time in this case).

Taking it further on this path you realize that you need to build the product for the user and target that value towards the customer. If we’re talking about the same person, hey, it gets easier. If they’re different think about what value your product brings the user and what value it brings to the customer.

For the purpose of this series and taking into account that for dailytraks the users are the customers I’ll just use customer to refer to both.

Why is it important?

Well, if you’re building something, you want to built the right thing. It’s easier that way :)

The only way you can do that is to figure out what your customer needs. What problem is your product solving for the customer. To do that you need to know who is your customer.

Taking it in the gray area of marketing and product development you need to figure out what your target market is. Who’s that specific guy or gal that has a problem and is willing to pay you to solve it.

You need to go deep down and dirty and figure out exactly who it is. Not just “Internet users”, or “old people” or even “moms”. You need to think about “30 year old moms living in Detroit, that drive a Chevy, have three kids and love Leo DiCaprio”. You need it because you’re going to drive your efforts towards delivering a solution to their specific problem.

It also gets easier to make product related decisions once you realize what your beachhead market is. Quite a military term for something so harmless.

So, to conclude. You find out who your customer is. Who’s gonna pay for it. Once you do, you trim it even further, refining it until you get a homogenous mass of people that need the same thing, in the same way and are willing to pay for it. They may even look alike.

clone_armyHaving this group of people that have the same needs and that look alike helps you define what your product is, what it does, what are the priorities for your product attributes or features and how much money you can make from it. We love building things but it’s really difficult to be innovative on an empty stomach.

There’s alot of information on how to do this, books, articles and even online courses

Back to dailytracks

Going back to our little experiment, dailytraks is a place to write down something daily.

Because this “something” is vague the beach is really big. It’s like “who can use this?”… “humanity”. That’s not good. We need to take it down a notch.

First let’s set some basics down:

  • “something” is text, and a date. it has a date. the date you write it down
  • it’s not about the future, although it may be. to be screwy, let’s make it about the past. what you’ve done, not what you’re going to do. it’s not a plan, it’s a history. OK. you can’t write something in the future. you write it today. it’s about today.
  • who does that? well, everybody. who does that religiously? well, professionals, like a captain’s log, or “what I’ve done today so I can bloody remember it when I have to send my task update, so I can get paid”. and schoolgirls, writing a diary. and weird guys writing down impressions about their one-night-stand. let’s just keep captain’s log and my lovely diary, that’ll do it.

See? We’re narrowing our customer base. It’s not about humanity anymore. It’s about ship captains and schoolgirls. Figuratively speaking that is. But it will do for now.

That’s a good start. We know have a vague idea about who our customer is. Somebody that records events at regular intervals, private events that is.

We think that professionals and young people writing a diary are a good general match for what we want to build. This helps narrow things down but it’s still not enough, it needs some validation before we start to invest anything in this idea.

We need to see that the need exists, that people might be into it, that they’re willing to part with their money for it and frankly, saying “professionals and young people writing a diary” in the same sentence sends a shiver down my spine, so the next step is to ask around, see how it fits, drop one of the groups and drill down in the other group.

You know, ship captains wouldn’t use a pink “my unicorn” diary for their daily log, they’d would a leather-bound ships log, and we can’t build both.

dailytraks – a mini-product from scratch – #2, the name

In my previous post I introduced you to a mini-product that I’ll be building in the open.

I talked about the idea, or the “why” of our product.

But hey, if we’re going to build a product we need a way to refer to it… basically everywhere.

It’s OK to call it “the product” but that’s cold and inexpressive and we don’t really like that, so we’ll need a name.

Don’t worry, this doesn’t have to be the final name – most likely it won’t be the final name – it just has to be easy to remember and easy to pronounce. Having a fun, catchy name helps.

So how do you get one?

Well:

  • you can be creative, like you know, randomly open a page of a book you like, or invent a new word
  • you can use a random name generator online
  • get professional help
  • brainstorm with colleagues, friends, family members or even strangers

At this point getting professional help (marketing, copy, branding, etc.) is premature. You can do that later.

Right now you just need a way to refer to your product – when talking to others or even thinking about it.

If you strike it lucky and find one that also reflects the why, even better.

I actually got to “dailytraks” by brainstorming with strangers. How? I went to http://chat.stackoverflow.com/ and asked.

names

After about fifteen minutes of that, some synonyms and abbreviations later and I got to dailytraks.

I like it, it reflects my why and because I cheated (checking domain names while brainstorming) I have a viable domain name for my product, which I actually bought off GoDaddy 5 minutes later.

 

Now, you shouldn’t go grab a domain for your product while you’re putting together your idea and thinking about a product name. I did that so I can brag about it in this post :)

dailytraks – a mini-product from scratch – #1, the idea

Because I need to tune my process I’m going to build a mini-product from scratch. First, some history. Once upon a time… just kidding.

 

So let’s begin.

The core product, idea, “the why” or the “benefit” is the first thing that we need to figure out. That’s the need for the product, and the seed crystal that everything else gravitates around.

You can get it from an instant flash, an organized idea pool or brainstorming session or you may even steal it (and make it better of course).

For this experiment everything started with a funny tweet from @notepadconf that led to me an article on lifehacker and then it hit me – an app that you can use to jot down  a little bit of text every day, like a daily log, a diary of sorts, or even a small poem is good idea for a semi-useful mini-product that wouldn’t draw me in the technical side of things but it would:

  • allow me to do an end-to-end product development tracer, from nothing to something user-accessible
  • allow me to fine tune my toolbelt and try some experiments with new third-party services

So, although you may just say “I’d just go and use Evernote” or “that’s what a text file on Github is for”, it’s not about that, it’s about building something new from scratch, in the open, as a kata.

Although ideas are pretty important, it’s good to know that they don’t hold all the weight. The implementation is far more important than the idea so don’t stress about you “giving your idea away” (if you’re working in a really competitive R&D sector I’d hold back on discussing my ideas, but most of the time nobody’ll steal your idea and work on it for a couple of years before it bares fruit) and talk freely about it – it helps.

So, my why is this: “Every day I write information in a text file on my desktop, I usually write small todos or snippets of text or things I’ve done, or some URL I want to revisit but I seldom do, or I delete it, or I forget to look at it ever again. I’d like to not lose this information, be able to look it up using a calendar, have it searchable, and from time to time randomly pop-up one of my dailies”

So my double personality is my client, and it has a need. That’ll have to do for now.

the static asset pipeline – optimized production experience, uncompromised development flow

Taking an app to production successfully brings a whole new set of challenges. Everything from user experience, resource usage and server load can be influenced by the way your app interacts with web assets such as JavaScript, CSS, fonts, images and even multimedia files.

Good user experience and low resource usage demands having as few server round-trips as possible and retrieving assets that are optimized for bandwidth and browser processing (or even resolution-optimized images and multimedia assets).

These requirements may complicate or even compromise your development flow, slowing you down and sometimes making it cumbersome to debug. That’s something that we definitely don’t want.

Here’s the deck to a short talk I had about the subject where I dive into the static asset pipeline, what problems it can solve, how it integrates with your environments (development, test and production) and the tools that we can use – https://bcostea.github.io/static-asset-pipeline/slides-static-asset-pipeline.html.

There’s code with that, you can grab it on GitHub: https://github.com/bcostea/static-asset-pipeline

If you’re interested in the subject add a comment or ping me @bogdancostea

accessing ruby I18n locale messages from the web client

I like to keep my client-side code completely decoupled from the server-side but I still want to keep one message source for localization.

The ruby stack I use includes Sinatra, Sinatra::I18n and the I18n gem for localization and this is the simplest and most effective way (that I’ve found) of accomplishing this:

The Sinatra route:
get '/locales/:locale_name/messages.js' do |locale_name|
    locale = locale_name.to_sym
     
    if I18n.available_locales.include? locale then
        messages = I18n.backend.send(:translations)
        "var m = " + messages[locale].to_json 
                    + "; t = function(k){ return eval('m.' + k); }";
    else
        not_found
    end
end 

This way the yml locale file is loaded and served and wrapped for quick use.

In the client just request the messages script and then when you need a message call t(‘message key’) just like you’d do it in ruby :)


var message = t('message.key');