Building a product to learn product development

Suppose you have an idea of a product would like to build, say something like twitter. Maybe for learning purposes but you wish this product becomes successful too in sense being used by atleast 10000 users.
You have already visioned the product way ahead but you beleive that this could be something important.

How will you approach building this product? Prototyping, Designing, Testing, Development, Customer Validation - What will the steps one should take to build a product and get it to market and be able to iterate easily based on the customer feedback.

How important is the testing( code testing) in this case because you are more concerned about getting this product out to the users.

The previous company I was in shut down in 6 months because they could not get enough users. We did not write tests and my boss beleived it is more important to get the right product than waste time on testing.

How true is this? I am really really confused about product development. There are way many differences between creating a product on your own or building for other startups.

I have an idea and I believe I have finished developing it but there are not specs written but they are still many features I could implement but I would rather take customer feedback and go ahead rather than use a waterfall approach.

@cpytel @benorenstein if you guys could help me showing the right direction :). My dream is to become a better backend developer but also create a kick ass product but not sure how I can go ahead with this dream.

Will getting a personal mentor help me in this quest. @cpytel I am in no mood to cancel my upcase services for another year.

Isn’t that the sort of thing that The Playbook covers?

When you are fully up to speed with TDD it doesn’t slow you down, it makes you go faster, especially when it comes to confidently making quick and drastic changes as you learn and change your app.

If validation of the business is not yet complete, than the primary task of the team should be to validate it. It should really be done while writing as little code as possible. This can include paper prototyping, wire framing, mock ups, and throwaway prototypes (untested) that are as quickly as possible put in front of potential customers to validate the business idea. This is usually done in just a matter of days.

We use a structures process for this called the Product Design Sprint. Yes, we write about it in the playbook. We also have a blog post on this.

And here is some more further reading, not by us:


In my opinion your former boss was wrong. The right product is 1) testable, 2) maintainable and 3) fast to fix when broken. What slows development down is learning our tools, usually. This site is chock full of information on the Right Way. 30 years managing software teams tells me that no matter which methodology you pick, you need to remember you are working to serve the end user customer, not a process maven. You can get really far with a quick whiteboard sketch and a deployment checklist. Requirements ALWAYS evolve.