3 ms·

What I meant is that some ideas are very expensive and time consuming to turn into products, even if you work like hell to make sure you build something as mini

What I meant is that some ideas are very expensive and time consuming to turn into products, even if you work like hell to make sure you build something as minimal as possible. If you're working on an idea like that, and you believe that you can't truly iterate until you release, then these ideas are less iterable. Of course you can try and test the idea against the market before you build the product - talk to customers, create focus groups, do dummy advertising to gauge customer response, but you can't really know until you build the product. For example, we're building a very high performance database. This type of software, even in its minimal conception, takes at least a year to build (at best). We talk to customers as much as we can, and we've adjusted our direction according to their feedback, but we can't iterate on this in the same way as the web guys can. We can't release a slightly different version every week and see what happens, we have no choice but to collect requirements, make the best judgements we can, and build according to those judgements. If, after a year or two of building, we find out that our product doesn't sell, we will have spent a lot of time and money at that point, and our options will be very limited. We can't easily switch direction because the software is so complex to build, and we can't do many incremental releases because the deployment process to customer sites is very time consuming. If you have a suggestion on how to iterate this type of project, I'm all ears :)

chrischen 17y ago
> ...but you can't really know until you build the product. I agree with you completely and this is exactly what I originally said. > If you have a suggestion on how to iterate this type of project, I'm all ears :) In the end you'll have to answer to reality right? Iteration is a process that's as valid for you as it is for a web startup. It may be a longer process for you because you're working on cutting edge technology, but in the end you still have to answer to reality. Let's say I am designing a user interface. This is something easily testable. I could try a blue colored button and see how users react. Now I must figure out how to change the color of the button to blue. I figure out that if I add background-color:##0000EE to the CSS it accomplishes this. Great! Technical feat accomplished. I think in your situation you want to figure out a) do users want our new database and b) how to create this new database. This would be analogous to a) do users want blue buttons and b) how do I make blue buttons. In web development changing the buttons to blue is trivial, so we can easily test if users actually want blue buttons. Iteration is so much easier in web-development because a lot of the stuff isn't technically challenging. But this doesn't mean other industries like department stores, electronics companies, and database companies don't have to answer to what ultimately works. Your database company, if it largely exists to implement one single idea, and test one single idea, is then simply at the stage of the iteration process where I was figuring out how to technically achieve that one iterative change. But I do agree with you in that in this type of startup, you would probably have to get a little more detailed as to how you operate. I would liken your effort to one of creating a time machine, or a fusion energy engine. If you're implementing something as new and innovative as a time machine, or fusion energy, I would imagine that at this point iteration is of non-concern, because you have yet to even complete one iteration of the idea. But I'm assuming your idea is not as technically challenging or revolutionary as a time machine or fusion energy (no offense!), and that you're getting into the implementation details already (since you mentioned talking to customers and focus groups, I'm guess you've already overcome the majority of the technical challenge). If you don't have a completed product to release and are still in the process of conceptualizing an idea and guiding the evolution about to take place, then you're a little more zoomed into the picture. In this case you don't iterate the idea just yet, but you would iterate the developing idea. In my opinion the best preparation is to look at history. Examine what worked in the past and identify patterns and roots of problems, not just examine the present. History is the combined repository of knowledge acquired from everyone else about what worked and what didn't. You could possibly gain access to some guy who already iterated many things for you and is telling you what he knows. I'm sure it's obvious, but so many of my friends undervalue the importance of history education. Learning from other's mistakes is probably more valuable from learning from your own, since other people, combined, have made way more mistakes. By obtaining past knowledge, this would be the best way to revise your idea before it's completely solidified for the first iteration. If you already completed the core of your product, then there's little recourse to salvaging a faulty product without morphing it completely. I'm assuming most of your money is spent developing one important technology, and that is the reason why you won't have room to change if it doesn't work? If it doesn't work, then it doesn't work. The point of iteration is to swap out what doesn't work. If it so just happens to be the foundation of all your improvements, then there's no helping that. You could identify a specific reason why it didn't work, and iterate again by replacing that huge undertaking that didn't work. It would still technically be an iteration, from your perspective, even if it means starting a new company with new investors. That core idea may not have worked, but that wouldn't necessarily mean the improvements you got right along the way were bad. They can still be applied to a new core technology that you swap in that works. Iteration is what the people in a business do. The idea is what gets revised in the process. An idea can always get revised, and always should be in order to conform to reality.

chrischen 17y ago

> ...but you can't really know until you build the product. I agree with you completely and this is exactly what I originally said. > If you have a suggestion on how to iterate this type of project, I'm all ears :) In the end you'll have to answer to reality right? Iteration is a process that's as valid for you as it is for a web startup. It may be a longer process for you because you're working on cutting edge technology, but in the end you still have to answer to reality. Let's say I am designing a user interface. This is something easily testable. I could try a blue colored button and see how users react. Now I must figure out how to change the color of the button to blue. I figure out that if I add background-color:##0000EE to the CSS it accomplishes this. Great! Technical feat accomplished. I think in your situation you want to figure out a) do users want our new database and b) how to create this new database. This would be analogous to a) do users want blue buttons and b) how do I make blue buttons. In web development changing the buttons to blue is trivial, so we can easily test if users actually want blue buttons. Iteration is so much easier in web-development because a lot of the stuff isn't technically challenging. But this doesn't mean other industries like department stores, electronics companies, and database companies don't have to answer to what ultimately works. Your database company, if it largely exists to implement one single idea, and test one single idea, is then simply at the stage of the iteration process where I was figuring out how to technically achieve that one iterative change. But I do agree with you in that in this type of startup, you would probably have to get a little more detailed as to how you operate. I would liken your effort to one of creating a time machine, or a fusion energy engine. If you're implementing something as new and innovative as a time machine, or fusion energy, I would imagine that at this point iteration is of non-concern, because you have yet to even complete one iteration of the idea. But I'm assuming your idea is not as technically challenging or revolutionary as a time machine or fusion energy (no offense!), and that you're getting into the implementation details already (since you mentioned talking to customers and focus groups, I'm guess you've already overcome the majority of the technical challenge). If you don't have a completed product to release and are still in the process of conceptualizing an idea and guiding the evolution about to take place, then you're a little more zoomed into the picture. In this case you don't iterate the idea just yet, but you would iterate the developing idea. In my opinion the best preparation is to look at history. Examine what worked in the past and identify patterns and roots of problems, not just examine the present. History is the combined repository of knowledge acquired from everyone else about what worked and what didn't. You could possibly gain access to some guy who already iterated many things for you and is telling you what he knows. I'm sure it's obvious, but so many of my friends undervalue the importance of history education. Learning from other's mistakes is probably more valuable from learning from your own, since other people, combined, have made way more mistakes. By obtaining past knowledge, this would be the best way to revise your idea before it's completely solidified for the first iteration. If you already completed the core of your product, then there's little recourse to salvaging a faulty product without morphing it completely. I'm assuming most of your money is spent developing one important technology, and that is the reason why you won't have room to change if it doesn't work? If it doesn't work, then it doesn't work. The point of iteration is to swap out what doesn't work. If it so just happens to be the foundation of all your improvements, then there's no helping that. You could identify a specific reason why it didn't work, and iterate again by replacing that huge undertaking that didn't work. It would still technically be an iteration, from your perspective, even if it means starting a new company with new investors. That core idea may not have worked, but that wouldn't necessarily mean the improvements you got right along the way were bad. They can still be applied to a new core technology that you swap in that works. Iteration is what the people in a business do. The idea is what gets revised in the process. An idea can always get revised, and always should be in order to conform to reality.