Six things to learn from the iTunes Story

I just read the iTunes chapter of Steve Job’s bio last weekend and it just completely full of business lessons. Here are some I observed:

Background: Consumers wanted to download songs into their computer, into their iPods, and there was no easy way. Buying CDs offline and then ripping them into the computer was a bit too inconvenient. So consumers used to download using file sharing networks. Piracy. Apple solved this grave problem for the music industry, by creating a way for people to download songs legally from their computer and pay for them.  iTunes store was the solution.



  1. Apple solved this problem in a way that kept the consumer in mind. Consumers could buy individual tracks from the album (and were not forced to buy the whole album). Completely untraditional.
  2. Sony was in a much better position to do exactly what Apple did, probably better. But organizational mis-alignment was a huge handicap for them. (Music and tech departments could not work together to come up with something that worked for both). Organizational mis-alignment can make you lose on huge opportunities.
  3. The pitch that Steve made when revealing the product was 1) High quality music  2) A way to try songs before you buy 3) Good karma (no stealing). Steve talked about ‘Karma’.  A sales pitch that directly hits the soul. Wow !
  4. The end-to-end integration between iTunes, iMac and iTunes was completely seamless from day 1. That says something. When you launch a product, make a compelling story.  Think through the experience.
  5. A Million songs sold in 6 days. Obviously huge success, but it also tells that Apple’s infrastructure could scale to support that kind of traction in the first week itself.  When going live and trying to make it big, keep high standards for your platform infrastructure.
  6. Microsoft and Sony tried replicating the same model with their devices, clouds, but Apple kept launching newer  & better versions of the iPod.  It was very hard for the competitors to grab a significant market share. Lesson: For product companies – the speed of innovation and delivery is the ultimate competitive advantage.

Would like to hear your thoughts on these / any other observations you made on iTunes.

A Practical Approach to prevent sprints from becoming mini-waterfalls

Let me admit. Preventing sprints from becoming mini-waterfalls is hard.nature-waterfall

There are interesting articles out there (here & here) which explain how agile sprints are different from waterfalls.

The thing is to break big requirements into small byte sized user stories and deliver a few stories in every sprint. But the essential 4 step sequence does not change –1)  Requirement Analysis -> 2) Design -> 3)Code -> 4) Test

Teams start doing these 4 steps for each story within a sprint.

Update: This is fine as long as you don’t have any new type of requirements, for which the steps 1 & 2 are significantly time taking. Or the estimates are going to be hugely different based on the design. Meaning situations where lets say a new architectural block needs to be brought it, or a major arch/ design change needs to happen.

If you do have to bring in a major change in steps 1 and 2, then there are 2 problems here:

  1. Since the requirement has not been analyzed very well and the technical design is not done yet,  the estimates for these stories are going to be highly in-accurate.
  2. Second problem is that you would want to do related stories together with the intention of solving one ( or maybe two)  user problems in a given sprint.  If these stories are related then step1 and step2 cant really be parallelized for these related stories.

As a result the team would be doing step1 and 2 for the related stories in the initial phase of the sprint. Then the team would get to coding and then testing.  Producing almost waterfall ? Also, there is going to be very little certainty on the estimates & high chances of missing the sprint goals.

The Approach to mitigate the above problems:  Do the requirement analysis and the high level design before your main sprint starts. Meaning, take up these steps as a part of the previous sprint plan.

Here is how it looks:


Sprinting nicely

The orange boxes are the key.

Some part of the analysis( in the orange boxes) can happen as a part of the sprint pre-planning exercise and some can happen as dedicated stories for the team to work on.

Obviously, this wouldn’t be possible for when you have completely new stories coming in the next sprint which were not planned in advance but try to avoid that situation from a Product Planning/Scheduling standpoint. Also, stick to 2 or 3 weekly sprints.  The above approach would be very hard to do in-case 4 weekly or longer sprints.

This is what worked for me, would love to hear your thoughts and experiences in the comments section below.

One change to make your sprint retrospective highly efficient

Context: Agile Product Development.

(Thanks to Inkcinct)

Agile (and scrum) is all about adaptation, quick improvements. I have written a a bit on making 2 week sprints effective & conducting sprint demos. But Sprint Retros are at the heart of agile are an equally critical part of the scrum / agile process.

At times,the retrospective meeting can be very time consuming, sometimes goes on for more than an hour. Here is the one change that could make it highly efficient :

  • Have a standard list of fine grained questions about the sprint for everyone one to answer. And they can only choose to answer between – agree / neutral  / disagree. Later provide details about their opinion.  
  • Put this list on a shared space ( either a google spreadsheet or the wall where people can vote using markers/ stickies or any other tool) and request all the team members to fill it up in the first 5 minutes of the retro meeting.
  • Start with questions for which everyone has voted – ‘agree’. You can ask the participants to provide some quick explanation on what makes them agree and what is it that the team should continue to do. This should be about 5 minutes.
  •  Next go to those questions which have ‘neutral’ or ‘disagree’ votes and then do the same thing – ask participants to provide details on why they disagree.  This is the main thing. Create action items out of this discussion and assign owners. Spend the bulk of your time here.

Having that standard list to begin with will save you a ton of time. It had started saving around 40-50% time for my retrospect meetings.

In-case its helpful, here is the list of questions I had used for my meetings, you can make your own

  1. Did we meet our sprint goals ?
  2. Did we do well w.r.t work allocation ? Our goal is to ensure that the allocation is not too heavy for one individual or a few individuals but is mostly evenly spread.
  3. Did we execute well ?
  4. Did we avoid fire fighting /working late in the last 2 days of the sprint ? ( We want to make sure that we do not have too much to do on the last 2 days)
  5. Did we do well on estimation ?
  6. Were the stories clear ? Was there no confusion w.r.t what was expected or acceptance criteria ?
  7. Did we do well on collaboration w.r.t UX, Product and Engg ?
  8. Did we do well on quality ? Our goal is to ensure that we dont leave major bugs as spill overs
  9. Did we do well on automation/ code coverage ?
  10. Do we feel equiped to deliver with speed ? Do we feel we have all we need for being productive ?

And if you are looking for material on how to conduct retros – here is detailed article by Microsoft.

Do give this change a try & share your thoughts on the above.






The only way to make 2 week Sprints Effective

(Context: I am talking about software development teams, who ship using agile methods)

There is only one way: Automation. Automate everything – tests, build, deployment, monitoring, failure notifications. Every kind of test.

I have been in various teams / products where we tried doing this and failed. But lately also part of team where we had accomplished this to a great extent.
Here are the usual symptoms of teams NOT able to accomplish this:
  1. There is a ‘code freeze’ and then there is a dedicated time span – about a week for the QA folks to test the coded new functionality. That means only one week’s worth of code is going to get shipped. Isnt that too little.
  2. Another one is that several bugs get introduced in during these rushed releases.
  3. The QA team is under immense pressure to ship within the given timeline.
  4. The initial part of the sprint is where QAs have lots of free bandwidth.
For a heavenly sprint Automate the builds / deploys and automate tests at various levels.
Unit tests, functionality / UATs test automation, automate code coverage measurement, automate look and feel testing, automate security and performance testing and setup rules that if any of these produce major failures – then fail the build and send a notification to the developers / whole team.
Comprehensive Automation keeps the quality bar really high. At the same time, the developers & testers have to be on their toes to be able to produce such a level Automation.
When this happens here is how a typical sprints looks like:
  1. Dev and QA are involved early on during the design / requirement understanding stage.
  2. The sprint deliverables are broken into small byte sized tasks. Most of which can be coded in less than a day / 2 days.
  3. As and when these tasks are coded, QA starts testing them ( including automating their tests).
  4. Towards the end of the sprint only a few ( say 2 ) tasks are still being coded which typically finish on the second last day.
  5. And there is this last day for testing to finish off stuff and devs to fix any bugs.
  6. Last day EOD – release !
So practically the ‘code freeze’ duration is just one day (or less). Heaven, isnt it  ?

Automation is an engineering team’s brahma-astra to achieve God speed.

May automation be with you ( may God be with you 🙂 ) !

How to do a Perfect Sprint Demo

I am talking about Product based companies developing software using scrum methodology. And I am talking about the ‘demo’ and not the sprint review.  The sprint review typically happens at the end of sprint with Product Manager(s) & Designer(s), who review the output of the sprint about what was committed & what got delivered. 


The Sprint demo is about showcasing your work to a wider audience, senior stakeholders, your consumers, operations, marketing, sales people etc.  I have done dozens of these & experimented with some formats.Here is what worked the best for me:


  • Total Meeting time: 30 mins
  • Walk through a summary Deck: 5-7 mins
  • Show the demo: 5-8 mins (max 10 mins)
  • Q n A: 15 mins.


  • Prepare a 3 slider deck.First slide – a summary of all functional stories delivered in the last sprint, second slide  – non functional, 3rd slide – defects & sprint metrics
  • Prepare a video of the demo. If you want to show a web app for example, show what you want to show on the browser and record it in a video. You can use snagit or quick time for recording a screen cast.
  • Now this video is the most important and trickiest bit.   For this you need to first write a small demo script – which would explain what would happen on the screen and what is the presenter supposed to speak at that time. Meaning what are the audience going to “See” and “hear” in the demo. ( its almost like writing screen play of a movie 😉 )
  • Write the screen play :
    • You need to weave all the stories delivered in the last sprint in an easy to follow video movie.
    • Make sure you give enough pause at each step where you can talk about what the audience are going to see next.
    • So things like clicking on a link, expanding a particular section, scrolling down a page – need an explanation as to why you are going to do that and what should the audience expect to see. So keep that in your screen play.
    • Repeating a point sometimes does not hurt.
    • Write a flowy script & tell a story about what real user problems are being solved.
  • Rehearse the script by following the steps on your software. When you feel ready, record the demo video.
  • Ideally you should record your voice along with the video too. ( this would be useful when you share your video with folks offline)
    • While recording your voice – use an excited & happy tone.
    • Give pauses at the transitions, tell them what they are going to see, after they have seen it, repeat what they saw.
    • Go in a flow, but at the same time, be a bit slow so that audience get time to soak it all in.
  • When the video is done, rehearse a bit again – be ready to give your confident voice during the actual demo.

At the Demo 

  • You are at stage.  Be confident. Welcome people with a smile 🙂
  • Set an expectation that questions ideally should be raised at the end.
  • Start with the deck and then quickly get to the video. ( you need to finish both in 15 mins)
  • Ideally, having the deck open in a small window on the side while the video is running helps.The audience can always see on the side to know what all is being covered in the video. ( or you can weave the deck into the video itself  – for a making it even better  )
  • Play the video and give your voice during the demo. ( Although the voice is preRecorded too, but keep that on mute, live sound energy is way better for a live audience 🙂 )
  • Make sure you sound energized and excited !
  • During the QnA round – if there is time left, feel free to call out individual attendees for their questions, comments, cover folks on the phone line too.  ( the names you noted initially would now help).

The above worked wonders for me, what about you ? Please do share your experiences below.

Moving from Engineering to Product Management: Challenges, Changes and a few tips.

Role Change
Role Change
(thanks to for the pic)
  1. Your “things to do” list would be overflowing ALL the time. Even if you take no more things to do and just work on the current task list, it may take you a month to just wrap up those. This would lead to a constant prioritization loop. You would always be prioritizing on whats important for you to do right now, today and this week.
  2. No “Right” / “Correct” way of doing things.  You will need to figure out what works in your role, your product and your organization with your customers, your engineering team etc. This is very different from Engineering where you need to usually solve a mathematical looking problem and come up with the best suitable solution. Incase of Engineering generally the influencing factors (for your choice of solution) would be well understood so you can make a “well-informed” judgements.  This is very hard in a Product Mgmt role, the ‘influencing factors’ in your decision-making would be generally fuzzy. Many pieces of information would not be available.  Many data points would be un-verified. Many data points can be made available, but it would take a huge effort to gather those, and you would not have all the time for that  investment.
  3. Poor understanding  / standardization of the  role. Different organizations, different teams have very different understanding of what the Product Manager should do.  This leads to a lot of confusion, mis-understanding and the going gets tough. For example, I have seen orgs where PM defines what problems we need to solve, the use cases, business scenarios, HTML mocks ( if they are relevant), then leaves it to the engg team to build a system which can accomplish those goals.  I have also seen teams, where the Product Manager provides a requirements document which already defines an engineering approach for the problems to be solved and the engineering team is responsible for building that engineering approach( and does not care about the business use cases, scenarios). 2 extremes. Be careful about this clarity before you sign up as a Product Manager for a particular org (be it an org within the same company or a different company).
  4. Limited learning re-sourcesThere are a LOT of senior engineers to learn from. The knowledge and the wisdom has been gathering in this area for a long time and thus getting induced into this role and growing in terms of learing and executing best practices is rather easier because of the abundance of patterns. Product Management being a new role, has limited resources to learn from.
  1. You own the engineering re-sources now. You are the major influence on what engineering team should focus on. So be very careful in keeping your “hidden geek / developer” instincts under control. Hint: Don’t keep re-writing / cleaning up your software 😉 .
  2. Your tasks may run into several weeks / months (not days / hours) . Learn to live with that, don’t set or commit to aggressive timelines.
  3. There is no real boss now (like there was in the engineering days). You are the CEO of your product and your engineering team. Which translates to the need of a lot of self-motivation, self-confidence and drive. There may be times when you need a bit of appreciation for what you did or how you accomplished a task, but there would be no one appreciating you or watching you so closely (as would be the case in the engineering role).
  1. Learn to live with un-finished tasks.
  2. Learn to live with ambiguity, un-certainty.
  3. Develop a strong decision-making framework – work hard on your guiding principles and clarity on your long-term vision. Write your decision-making framework down – get guidance from your senior peers / bosses and make it concrete.
  4. Develop a habit to retrospect often, gather learnings and document them , share them. Add these to your decision-making framework as notes  / some other form. So that you don’t ever make those mistakes again.
Just my initial set of thoughts on this transition, would love to hear your comments. Please share your thoughts in the comments section.

How to Design: Think Top Down

I have been interviewing people on software design. I cant even remember in how many interviews candidates jump into designing the data layer as soon as the requirements of the software are provided. Only a magician can do this right.

(Thanks to for the image)

A normal engineer needs to think top down. The data layer is the foundation of the system.  Go to the foundation in the very end.

You start with a requirements and start defining functional blocks of your product. Think of it like different parts of machine, say if I were to design a car, i would think of the engine, the AC, the body, the seating etc as the “functional blocks” which are directly derived from the requirements.

These components need to be able to interact with each other to make the software you need.  You can call this a  “High Level Functional Components Diagram”.

Once you have this diagram ready, ONLY then you should get into the design of each of these components.

Take a look at this nice article on a structured design thinking and different perspectives which are important in a design process –

Is it really so hard to understand this 1 simple thing ?

“Dirt Mode” Software Development for SaaS / internet startups

Dirt Mode

Here is my 6 point definition of  “Dirt Mode” software development which suits developing new SAAS based  products. This is a practical software development style  and in some way supports the lean software development principles.

Dirt Mode
(thanks to for the image)
  1. Use a pluggable and adaptive design (adaptable to alternatives in technology). Dont integrate with any one particular technology too deeply.
  2. Don’t try to create a “sophisticated”  design / architecture.  Keep it simple and lean. Assume that you are going to throw it away the next quarter.
  3. Build no automation tests and write bare minimum UTs just for your own confidence on the code. You know that you may end up throwing the technology you are using, and adopt a completely new one.  Take a look at one of my earlier posts to see why it makes sense.
  4. Use Test Driven Development like technique – don’t write automated tests, but create a detailed test plan before writing code.  Spend time review these test plans more than the code. This would ensure that the code delivered in the first go is high quality with few surprises.   You would save a lot of time in code reviews.
  5. Be crazy about measuring software quality and success after launch.  You know that there would be surprises. If you get to see issues in the way it works today, be more than ready to throw away  / re-factor any of your components and do a quick re-write (instead of trying to hammer the same thing too much).  If you miss this one, it would be too late for you to do a re-write / throw away when your customers start telling you how buggy your product is.  So you should know how you plan to check if you software is working as it is expected to in the live environment before it becomes a big issue for your customers and your business.
  6. Be very careful about what technology you choose for your product. Relying on the latest may seem cool and fashionable but in my experience its a very risky thing to do un-less 1) you are developing this product just for the fun of it and you mean to make no serious impact OR 2) You are doing it for experimentation mostly for RnD. Try to use more mature technologies which have plenty of adoption and support.

Once you get a feeling that the design and technology choices you had  made are reasonably right which would happen after a few iterations depending on your initial attempt(s) , you can then start putting in the the heavy-weight stuff like automated tests, extensive UTs, hardening the design by integrating with the technology capabilities more deeply.

Also, the point #6 only makes sense when you have a variety of choices. If you are building something that depends on the latest technology that was released yesterday,  you have no choice.  Take the plunge !

These are my thoughts, I would love to hear yours. Please share your opinions in the comments section.

When you should NOT write Unit Tests

If you are developing a new product or a feature nearly from scratch and you are wondering if you should spend time writing UTs. You are probably thinking the right thing. (IMHO, if you think that you should always write UTs, you might be wasting a lot of time)

Let me try to keep this short and crisp:

  1. Typically if you are developing something new where features will keep getting added, subtracted really fast. You might realize that the core components might have to change. And not just change but might also vanish and new design components might also appear.
  2. So now your product is ready to go to the market and you just deployed your app on one of the hosting providers out there and you are now facing scaling issues – your app hangs when the traffic is on peak, you get 1000s of errors in the peak traffic time, your app is a memory hog and the GC runs a little too much.  All of this is happening and you are thinking of major strategic design changes to make your code light-weight and stable.
  3. Your product is now out there, does not hang too often. But you still see tons of errors in the logs.

Depending on how many surprises you are expecting in stage 1,2 and 3, you should delay writing UTs in the initial phases of the launch of your new app / feature.

And how many surprises you expect depends on how new is the app you are going to launch, in terms of the core design components, the kind of traffic its going to receive, the new features that you expect to go in and out in the initial launch phase.

I have had experience where we ended up writing lot of UTs while we were in phase 1 and then it became harder and harder to maintain the UTs sanity during 1,2. We realized that the kind of speed with which the design was evolving was a little too much to keep the UTs sane.

Once your app has crossed stage 3, you know you should start adding UTs for sure. At the same time be really careful, the later you start with the UTs the bigger would be the overhead of making a solid UT framework stand from ground-up.  To be honest, there is never too late for writing UTs, but there surely is too early, so understand your app and make your judgement call.

Monitor your system:Five things you must do

If you own a software/hardware deployment which serves your customers and the availability of your system is of high importance, here are the 5 things you can’t afford to miss out as far as monitoring your system health is concerned.

While this is no guide on how to setup monitoring, this definitely is a very quick and crisp check-list on bare minimum steps you MUST take achieve reliable monitoring of your system.

  1. Monitor your system’s availability through external pings. As an example, if you have an http based service, configure your monitoring system to hit your most important URLs at a particular interval and look for the response content and also make sure that the response is returned within a given time limit.  You should know which are the URLs which represent your application’s availability and are nearly mutually exclusive. This monitoring shows you how the external world perceives your application/server.
  2. Monitor your system’s internal health through monitoring agents sitting on your machines. This would include basic hardware metrics around CPU, Memory, I/O, Disk Space, Network activity, no. of processes etc and application specific metrics like – error counts in your application logs,  no. of requests, process health etc.  While the external pings may be looking green, there may be something cooking internally which can hamper the external availability if not stopped.
  3. Monitor your monitoring system’s availability through external pings. This one is special. People generally tend to miss this one out. What if your monitoring system go down? Will you get alert emails / smses if your application goes down when your monitoring system had crashed ? If you don’t have external monitoring on the monitoring system itself, you are playing a lot on luck.  In such a scenario, what you could do is to deploy a alternate system monitoring your application’s health. So if your primary monitoring system is down – most probably your secondary monitoring system would be up. So you have to have a secondary monitoring server, which would monitor either  the primary monitoring system OR the application itself.
  4. Clearly differentiate between critical and warning alerts. When you get an alert you should know how severe it is. If you can afford to ignore the alert for the next 2-4 hours, its probably a warning. If you are losing(or may lose) business every second you ignore the alert you can call it critical.  This is just a high level guideline, you should decide whats critical for you and whats not.
  5. Configure Instant notifications on your mobile for critical alerts.Your system might go down in the night when you are sleeping, it may go down on a Sunday or any other time when you are not checking your mailbox every 10 mins. If you really want a solid reliable monitoring system, this one is a super must.

While the above list is meant for your applications/server, you can easily relate the above strategy to monitor your own self as a leader 🙂 .