Disclaimer: All the thoughts expressed are my views only! Your perception might differ... 1. How different is product development? 2. What are the fundamentals of building a product? 3. How do I know that I'm at the wrong end of building the product? 4. Will you start building two products, if given a second chance? 5. All of a sudden I go blank, what should I do? 6. But my project is running on a delayed schedule, what do I do? 7. Pitfalls in putting out milestones? 8. Testing? what? 9. Do I make the team work 7 days a week? 10. why this faq? 1. How different is product development? For starters, they are completely orthogonal! I can hear you mumble "C'mon building a product cannot be different from building a framework." I learnt it the hard way! Yes, though they seem to be very much related, the subtle differences place them far apart! In developing a framework, you get started with whatever you have in mind. i.e you conceptualize your version of the framework. This will get you started, but after sometime, when you rope in a couple of customers, it is not you(framework team) that decide what goes in or what is useful! IT is mainly driven by the internal customers. They start defining the rules. This check ensures that whatever the framework team builds, is used effectively! Well, it acts as a guide post. The scenario takes a "U" turn with respect to product development. why? it is due to the fact that it is pretty difficult to rope in early customers. Unless they have an impinging need for the solution, they will not opt to be part of the early bird customer programs. So what can happen is the possibliy to get insane, "what might happen if this happens?" and you start fixing problems or developing features which might not be useful! This I would term as the "product developers" mind block. To overcome this we cross-verify ourselves with the competitors(EEE strategy), but down the line, it might not be effective. Because we tend to supersede the competitor. So always be watchful about what you put into the product. 2. What are the fundamentals of building a product? The most important aspect of the product is the conceptual integrity! Yes! that is the secret ingredient for making your product a success! Visualize how the end-user/customer will see the product. That will set things straight! Start looking at the product with NOT what you know, but with what the customer knows. The default behaviour of any developer is to fall into the habit of taking things for granted. i.e the normal pitfall is that once you get into the trees you tend to forget the forest( the overall picture!) Always concentrate on the forest and not on the trees! During the intial stages of the product, I missed it and I payed the price(extra time)! 3. How do I know that I'm at the wrong end of building the product? Well it is a tough question, let me give it a try... The moment you sit down to work, what is that flashes in your mind, "how to fix the issues?" "where to find the solutions?" "how could I nail this bug?" If you answer "Yes" to any of the questions, then you are seeing the trees! It is high time you start visualizing the global picture of the product. 4. Will you start building two products, if given a second chance? No, it is not OK! NEVER start two products at the same time, even when they are related. Normally what happens is that you tend to lose focus of one product or the other. Just postpone the start of the second product by 5-6 months. During which the first product would have come to a decent shape. It is just an balancing act! but your mileage may vary... 5. All of a sudden I go blank, what should I do? Well, this I would term as the Product developers "block". It happens, remember afterall we are human. Just take a couple of days off! and get started with a fresh mind! believe me it is normal! Just go ahead and talk with guys out there who has already built great products! 6. But my project is running on a delayed schedule, what do I do? Whatever I say out here will not address your problem. All I have to say is this, you underestimated the project time frame. Believe me all software developers are optimistic, no matter what, that is their nature ;-) This is Ok! as long as you acknowledge the delay and make an effort to make much better schedules. 7. Pitfalls in putting out milestones? Well it depends upon the product, if the product is very straight forward i.e without very high performance/scalability requirements, go ahead with your monthly milestone(s). But be careful while tagging the milestones. Because I faced the problem of running out of milestone numbers :-( and started calling it beta even before it was beta ready! 8.Testing? what? It depends on how much quality you want in your product! Normally it will take 1/3rd the time of the time taken to build the product! No matter how much pressure you have for monthly release, never compromise on quality! We talk about quality etc at the early stages,but sacrifice it in the name of time constraint! Never do that. What if the milestone gets postponed? it is ok! 9. Do I make the team work 7 days a week? Nope! whatever happens don't over do it! (I did it, I got obssessed with the product). Stretch your team only if needed! Well! it might be against the standard management philosophy were the more time you spend the more you gain! I totally disagree with this! Think about this, when is that you get the best ideas and solutions to your problems? I am confident that you don't get them at work! It happens only when you are away from work. Moreover, the nature of software job does not need the couontless hours. All it needs is a clear mind and very little time. But the industry is all screwed up! I took a shot at it but in vain... but I am sure I would break it someday in the near future! Here is an interesting tid-bit: I came across a international study about the productivity of work(i'm sorry I missed the link), It states that on an average only 2 hours/day results in productive work! That means we spend nearly 6 hours a day (assuming 8 hrs as the working time) in communicating etc... Well, I could hear you shout at me, that is not possible, well try for yourseslf! Before that ensure that what productive work is! Anything that you to attain the goal of the company is termed productive. Another word of caution is that this time frame is only an average over a week, i.e you tend to be more productive on some days only! 10. Why this faq? There are two ways to learn anything in this world, one the hard the way and second learning from somebody else's experince. I learnt the hard way, I want you to learn the easier way! If this enlightened you, here is what I want you to do... share two of your learnings that would do! Hey I have more questions what do I do? well you have couple of options i) read some books esp Mythical Man Month (a must read for product leaders) ii) discuss with people who have already crossed it or iii) learn it the hard way! |
