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.

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

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

cause and effect – more testing doesn’t necessarily improve software quality

A short story about cause and effect I had in my backlog.

Jim works for a software company or, why not, he may even own it.

Jim realizes that the quality of the software that gets built in his company decreases year-by-year, all over the board. He’s been seeing it for some time now but it seemed like the guys have it under control. You know, the guys know what they’re doing.

After awhile things seem to slip even further….

Continue reading cause and effect – more testing doesn’t necessarily improve software quality

competing for your time

If there’s any single thing that you’ll never get back, it’s time.

Time is the most valuable resource that you posses. It’s your currency.

Things and people are in a never-ending race, competing for your time, but ultimately, if you respect your time, you should decide who receives it.

Lao Tzu said “Time is a created thing. To say ‘I don’t have time,’ is like saying, ‘I don’t want to.” and that’s… well, deep and true.

Only give your time to the people who respect it and to the things that given time, will give it back to you.

Because the people who respect your time will use it wisely while the rest will just waste it.

Saying that you don’t have time for something is lying to yourself and others. Give it some time tomorrow, or if you think that it really doesn’t deserve your time… don’t do it.

semantics

Back when I was green and naive I thought that real physical things are valuable.

I thought that people work together based on common interest, as opposed to working together based on the intersection of personal interests. I know, it seems like a semantic difference… it’s not.

Once you realize that this is a fact, not just some philosophical gibberish your whole collaboration mindset will change.

Nobody actually wants to work toward a distant goal that will benefit us all, without searching for a personal benefit. You’ll find people who swear their allegiance, ready to do anything to prove their pure intentions. That’s just their subconscious pulling tricks on them. They’re internal subconscious radar is scanning for gain 24/7.

“Help me help you” wins every time, it’s a better, more sincere strategy.