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?


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


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); }";

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');

new endeavours – things to avoid

When you want to start something new,  be it a business or a new product you always start up with an idea or, if you don’t have one you come up with one (by who care what process… brainstorming, calling a friend, stealing).

There’s no better idea than yours. I mean, it’s a pot of gold. What am I saying… it’s the motherload, the ultimate cash cow.

Well, before the money starts rolling in, you may want to analyse it a little further, especially regarding the intersection between your new idea, the boundary of your knowledge and the actual demand for a product such as the one you’re envisioning.

Here’s a diagram describing where you don’t want to be.

2014-01-26 Venn - Intersection - 1