3 ms·

I know it’s an april fools joke. But I’ve recently “discovered” why this is nevertheless very true. If you move slow, you have a higher chance of meeting the ri

by dstick 6y ago

I know it’s an april fools joke. But I’ve recently “discovered” why this is nevertheless very true. If you move slow, you have a higher chance of meeting the right customer, of actually allowing your idea to grow and improve over time. Without being locked into it in one form or another. Moving slow allows you to work on it as a side project first. Which means no financial stress. And then making things. To me this means no paper prototyping. Not selling people on your idea without having anything tangible. Some may call it smart. To me it feels like gambling with your believability / integrity. There are only so many times you can do this before people get tired of you and your stories / dreams / business ideas. Just make something, show it to people when it’s actually useful. And feel good about actually having made something people liked. Instead of selling something people liked and then suffer the feeling of non-stop pressure, constantly _not_ being where you’ve told others you are. Happy april fools :)

konschubert 6y ago
I think even when moving slow, you can still work with prototypes and get feedback as long as you're open about it and you're not taking people's money. For example, I have https://www.invisible-computers.com https://www.invisible-computers.com up as a website. You can read about the product and you can sign up to be notified. But I won't take a cent until I have a product ready to ship.
- dstick 6y ago
  I agree, but the general consensus in startup pop-literature (is that a thing? :D) is that you can never be sure unless you ask money and people are willing to pay. Otherwise people can just say they like / want / need it, without risk. I have to say that I agree. Too many times I've experienced that people _say_ they'll pay, but never actually do when push comes to shove. But when someone does agree to pay (meaning you've somewhat validated your idea) then you're left empty handed and have to backtrack with your first customer. Not a great start. But that's just me :) YMMV
  - konschubert 6y ago
    Agreed Of course a newsletter signup is not a sale. Not even 1%. But it’s still a signal. And selling something you don’t have is borderline fraud in my book. Even if you backtrack and refund, it was still a lie and a waste of the customer’s time. Also if one is selling something one should be aware that now you will have to support it for the next 10 years, even if it turns out to be an unprofitable business.
- lupire 6y ago
  Cool product. 1. Why "Invisible"? 2. Why such a thick frame? I hope you expand frame choices, or offer a minimal version that customer can frame. 3. I guess you are building a custom UI layout for the calendar data, but please allow any URL to be loaded in the frame, so the community can build custom data views.
toyota86 6y ago
Relevant to your process of discovery > There once was a Master Programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the Master to evaluate his progress, the Master criticized him for writing unstructured programs, saying, "What is appropriate for the Master is not appropriate for the novice. You must understand Tao before transcending structure." ~~The Tao of Programming
ChrisMarshallNY 6y ago
This pretty much defines how I work. I “move slow,” taking the time to test carefully, and leave clean, concise, well-documented code, but I’m told that I actually move at a blistering pace. I have found there is absolutely no substitute for having an operational, full-feature implementation (I hesitate to call it a “prototype,” because it needs to be fully functional, not just eye candy). I am not a fan of lash-up prototypes, because they invariably become ship code, and starting on a foundation of sand is a very, very bad idea. I short-circuit that, by writing everything as ship code; even my A/B experiments. I can often recycle the rejected code for other projects. It also saves a lot of testing time, as the code is being constantly tested from the start, and being tested while still in scaffolding (meaning more complete testing, overall). For example, in the app I’m developing now, I’m working on a dropdown screen that allows the user to define search criteria for a database lookup. It’s a complex and fraught operation, and I’ve already had to make a number of changes, based on actually using the facility, as opposed to thinking about using it. If I had simply solidified my original design, it would have been a mess. I will also be making sure that the facility works for different regions and languages, despite the first implementation being only for the US. It has been my experience that this kind of thing should be built in from the start, as retrofitting it is a nightmare (and bug farm). My approach does mean that I often need to rewrite a lot of finished, tested code, or throw out big chunks (which is one reason I have a bunch of small, polished, standalone package projects). It’s taught me to design and implement very flexible code (which is actually dangerous, so I often go back, and remove flexibility, once I have settled on an implementation). Nevertheless, I have found it’s the best way to end up with a usable, relevant, high-quality, finished product, that meets the customer’s needs, in a remarkably short time. DISCLAIMER: This is a viable way to design UX (the kind of code I usually write), but may not be the best approach for “engine” or algorithm code.
- NateEag 6y ago
  To prevent a prototype or proof of concept from shipping, you need to leave it feature-incomplete. The mistake people often make with such things is building it thoroughly enough that it can be shipped. If you hit that problem, you didn't build a proof of concept - you built sloppy production code.

by dstick 6y ago

konschubert 6y ago

I think even when moving slow, you can still work with prototypes and get feedback as long as you're open about it and you're not taking people's money. For example, I have https://www.invisible-computers.com https://www.invisible-computers.com up as a website. You can read about the product and you can sign up to be notified. But I won't take a cent until I have a product ready to ship.

dstick 6y ago
I agree, but the general consensus in startup pop-literature (is that a thing? :D) is that you can never be sure unless you ask money and people are willing to pay. Otherwise people can just say they like / want / need it, without risk. I have to say that I agree. Too many times I've experienced that people _say_ they'll pay, but never actually do when push comes to shove. But when someone does agree to pay (meaning you've somewhat validated your idea) then you're left empty handed and have to backtrack with your first customer. Not a great start. But that's just me :) YMMV
- konschubert 6y ago
  Agreed Of course a newsletter signup is not a sale. Not even 1%. But it’s still a signal. And selling something you don’t have is borderline fraud in my book. Even if you backtrack and refund, it was still a lie and a waste of the customer’s time. Also if one is selling something one should be aware that now you will have to support it for the next 10 years, even if it turns out to be an unprofitable business.
lupire 6y ago
Cool product. 1. Why "Invisible"? 2. Why such a thick frame? I hope you expand frame choices, or offer a minimal version that customer can frame. 3. I guess you are building a custom UI layout for the calendar data, but please allow any URL to be loaded in the frame, so the community can build custom data views.

toyota86 6y ago

Relevant to your process of discovery > There once was a Master Programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the Master to evaluate his progress, the Master criticized him for writing unstructured programs, saying, "What is appropriate for the Master is not appropriate for the novice. You must understand Tao before transcending structure." ~~The Tao of Programming

ChrisMarshallNY 6y ago

This pretty much defines how I work. I “move slow,” taking the time to test carefully, and leave clean, concise, well-documented code, but I’m told that I actually move at a blistering pace. I have found there is absolutely no substitute for having an operational, full-feature implementation (I hesitate to call it a “prototype,” because it needs to be fully functional, not just eye candy). I am not a fan of lash-up prototypes, because they invariably become ship code, and starting on a foundation of sand is a very, very bad idea. I short-circuit that, by writing everything as ship code; even my A/B experiments. I can often recycle the rejected code for other projects. It also saves a lot of testing time, as the code is being constantly tested from the start, and being tested while still in scaffolding (meaning more complete testing, overall). For example, in the app I’m developing now, I’m working on a dropdown screen that allows the user to define search criteria for a database lookup. It’s a complex and fraught operation, and I’ve already had to make a number of changes, based on actually using the facility, as opposed to thinking about using it. If I had simply solidified my original design, it would have been a mess. I will also be making sure that the facility works for different regions and languages, despite the first implementation being only for the US. It has been my experience that this kind of thing should be built in from the start, as retrofitting it is a nightmare (and bug farm). My approach does mean that I often need to rewrite a lot of finished, tested code, or throw out big chunks (which is one reason I have a bunch of small, polished, standalone package projects). It’s taught me to design and implement very flexible code (which is actually dangerous, so I often go back, and remove flexibility, once I have settled on an implementation). Nevertheless, I have found it’s the best way to end up with a usable, relevant, high-quality, finished product, that meets the customer’s needs, in a remarkably short time. DISCLAIMER: This is a viable way to design UX (the kind of code I usually write), but may not be the best approach for “engine” or algorithm code.

NateEag 6y ago
To prevent a prototype or proof of concept from shipping, you need to leave it feature-incomplete. The mistake people often make with such things is building it thoroughly enough that it can be shipped. If you hit that problem, you didn't build a proof of concept - you built sloppy production code.