You know who the best managers are? They are the great individual contributors who never ever want to be a manager but decide they have to be a manager because no one else is going to be able to do a good as job as them.
– Steve Jobs
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, product 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…Continue Reading “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 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…Continue Reading “dailytraks – a mini-product from scratch – #3, who’s gonna use it and who’s gonna pay for it”
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…Continue Reading “a mini-product from scratch – #2, the name”
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…Continue Reading “a mini-product from scratch – #1, the idea”
every problem is a people problem
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: 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…Continue Reading “accessing ruby I18n locale messages from the web client”
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 mother-load, the ultimate cash cow. Well, before the money starts rolling in, you may want to analyse it a little further, especially regarding…Continue Reading “new endeavours – things to avoid”
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"