Comments on: Departure: Noah Iliinsky http://blogs.exbiblio.com/2006/08/15/departure-noah-iliinsky/ Following the ups and downs of a high-tech start-up in Seattle. Fri, 04 Jan 2008 06:35:47 -0600 http://wordpress.org/?v=2.8.4 hourly 1 By: Francisco Soto http://blogs.exbiblio.com/2006/08/15/departure-noah-iliinsky/comment-page-1/#comment-109 Francisco Soto Tue, 29 Aug 2006 14:29:01 +0000 http://blogs.exbiblio.com/2006/08/15/departure-noah-iliinsky/#comment-109 Random, Although I see your point of focusing, you also have to consider what Ed said behind the politically correct phrasing, which is that as long as they are taking the right steps in the right direction: - setting up basic functionality of hard and software - analyzing and discriminating potential market areas - etc,... to come up with the final recipe is not the smartest aapproach. Fist things first, and then make decisions when is necessary, not before. For this I recomend the best lecture I have been to, back in 1999 by Monty Python's John Cleese: http://www.news.cornell.edu/pressoffice1/May06/CommenceCleese.html The book by Guy Claxton was also useful, but less funny. Regards, Francisco Soto Random,

Although I see your point of focusing, you also have to consider what Ed said behind the politically correct phrasing, which is that as long as they are taking the right steps in the right direction:

- setting up basic functionality of hard and software
- analyzing and discriminating potential market areas
- etc,…

to come up with the final recipe is not the smartest aapproach. Fist things first, and then make decisions when is necessary, not before.

For this I recomend the best lecture I have been to, back in 1999 by Monty Python’s John Cleese:

http://www.news.cornell.edu/pressoffice1/May06/CommenceCleese.html

The book by Guy Claxton was also useful, but less funny.

Regards,

Francisco Soto

]]> By: random http://blogs.exbiblio.com/2006/08/15/departure-noah-iliinsky/comment-page-1/#comment-107 random Mon, 28 Aug 2006 23:55:22 +0000 http://blogs.exbiblio.com/2006/08/15/departure-noah-iliinsky/#comment-107 "At this point the honest answer is that we have not found that magic combination of achievable functionality that we believe makes our complete product really useful. We call this critical utility. Until we reach that point, a bit of searching in the dark is necessary, even if it is painful at times." This is really really not a very hard thing to -unless- you are attempting to 'usefulize' (thank you g w bush) all of software and hardware. "As an organization we’re dedicated to creating useful products. Software and hardware that people really use every day of their life. " That's your problem. Narrow it down for goodness sakes. Focus on one or two things, and figure out how to do them well. After that, you can change the whole world. But start in your backyard. “At this point the honest answer is that we
have not found that magic combination of achievable functionality
that we believe makes our complete product really useful. We call
this critical utility. Until we reach that point, a bit of searching
in the dark is necessary, even if it is painful at times.”

This is really really not a very hard thing to -unless- you are attempting to ‘usefulize’ (thank you g w bush) all of software and hardware.

“As an
organization we’re dedicated to creating useful products. Software
and hardware that people really use every day of their life. ”

That’s your problem. Narrow it down for goodness sakes. Focus on one or two things, and figure out how to do them well. After that, you can change the whole world. But start in your backyard.

]]> By: Ed http://blogs.exbiblio.com/2006/08/15/departure-noah-iliinsky/comment-page-1/#comment-87 Ed Fri, 18 Aug 2006 21:34:48 +0000 http://blogs.exbiblio.com/2006/08/15/departure-noah-iliinsky/#comment-87 Francisco, as is often the case, certain components of our product are more clearly defined than others. In those areas where the product is well defined, like our hardware device, we are operating in an iterative, priority-based, risk-reducing development model. Other aspects of the product have much less clarity. As an organization we're dedicated to creating useful products. Software and hardware that people really use every day of their life. That is not an easy task, and requires that we always keep an open mind about what is useful and why. At this point the honest answer is that we have not found that magic combination of achievable functionality that we believe makes our complete product really useful. We call this critical utility. Until we reach that point, a bit of searching in the dark is necessary, even if it is painful at times. Francisco, as is often the case, certain components of our product
are more clearly defined than others. In those areas where the
product is well defined, like our hardware device, we are operating
in an iterative, priority-based, risk-reducing development model.
Other aspects of the product have much less clarity. As an
organization we’re dedicated to creating useful products. Software
and hardware that people really use every day of their life. That is
not an easy task, and requires that we always keep an open mind about
what is useful and why. At this point the honest answer is that we
have not found that magic combination of achievable functionality
that we believe makes our complete product really useful. We call
this critical utility. Until we reach that point, a bit of searching
in the dark is necessary, even if it is painful at times.

]]> By: Hugh http://blogs.exbiblio.com/2006/08/15/departure-noah-iliinsky/comment-page-1/#comment-80 Hugh Wed, 16 Aug 2006 13:02:41 +0000 http://blogs.exbiblio.com/2006/08/15/departure-noah-iliinsky/#comment-80 Francisco, You raise some important questions. I hope the the blog will carify some points over the next week or so. As an outside observer / blogger, I can't answer on behalf of Exbiblio. I'll try and russle up some answers from the Exbiblio people. Francisco,

You raise some important questions. I hope the the blog will carify some points over the next week or so. As an outside observer / blogger, I can’t answer on behalf of Exbiblio. I’ll try and russle up some answers from the Exbiblio people.

]]> By: Francisco Soto http://blogs.exbiblio.com/2006/08/15/departure-noah-iliinsky/comment-page-1/#comment-71 Francisco Soto Tue, 15 Aug 2006 12:30:11 +0000 http://blogs.exbiblio.com/2006/08/15/departure-noah-iliinsky/#comment-71 Excuse me, but after reading this post I have new doubts about the end product that ExBB is targeting. On one hand, it seems you are concentrating your product development towards a few areas well defined of function / users / environments. Like what backpack did for small web-pages: basic to the point of primitive, easy to understand and intuitive to use, limited functionality but over-delivering in what is promised, all of which ends up with happy users. If this is the case, you work with pretty concrete scenarios, deadlines, tasks, cycles, division of labour, financial forecasts, etc. A small army/cult with a small hierarchy but clear boundaries. On the other hand, sometimes the blog reads like what you are developing is more the technology that will cement targeted applications and uses, like developing an API that involves hard and soft ware. In this case, I suppose you work more like an R&D start-up, pushing boundaries through kibbles without overflowing the burn rate, output measured in IP, free association brainstorming from very different perspectives and experiences from a diverse group, and step by step clearing the fog around what the technology will be able to deliver. A flat organization of equals. I supposed this second scenario was closer to ExBB's reality based on what Tommy Arens said about the product lunch: that 'most of the anticipated uses will be greeted with “okay that’s nice”, and the one that really takes off will be thing that nobody ever thought about – that will be a surprise and it will be fun.' The fact that Noah thinks there is little definition of the processes and goals of product development portrays a need for a reorientation towards the first approach, and makes me wonder aloud if maybe that is the beauty of ExBB's approach: A middle way between concretion and 'too much vision' as the right way to advance at this stage of development. Excuse me, but after reading this post I have new doubts about the end product that ExBB is targeting.

On one hand, it seems you are concentrating your product development towards a few areas well defined of function / users / environments. Like what backpack did for small web-pages: basic to the point of primitive, easy to understand and intuitive to use, limited functionality but over-delivering in what is promised, all of which ends up with happy users.

If this is the case, you work with pretty concrete scenarios, deadlines, tasks, cycles, division of labour, financial forecasts, etc. A small army/cult with a small hierarchy but clear boundaries.

On the other hand, sometimes the blog reads like what you are developing is more the technology that will cement targeted applications and uses, like developing an API that involves hard and soft ware.

In this case, I suppose you work more like an R&D start-up, pushing boundaries through kibbles without overflowing the burn rate, output measured in IP, free association brainstorming from very different perspectives and experiences from a diverse group, and step by step clearing the fog around what the technology will be able to deliver. A flat organization of equals.

I supposed this second scenario was closer to ExBB’s reality based on what Tommy Arens said about the product lunch: that ‘most of the anticipated uses will be greeted with “okay that’s nice”, and the one that really takes off will be thing that nobody ever thought about – that will be a surprise and it will be fun.’

The fact that Noah thinks there is little definition of the processes and goals of product development portrays a need for a reorientation towards the first approach, and makes me wonder aloud if maybe that is the beauty of ExBB’s approach: A middle way between concretion and ‘too much vision’ as the right way to advance at this stage of development.

]]>