Power of “Breaking it down” – 10 minutes and NOW

It has been months since my last blog post. Call it laziness, lethargy, procrastination, sudden lack of confidence in my writing skills – every one of these had something to do with it. I used to tell myself that I had to do it. But never did it.

Last night, I was teaching my 9 nine year old daughter Navya how to compute the area of shapes. I was teaching her how to break the shape into rectangles and squares, calculate the area of each and then add them up. Suddenly, it dawned on me as to how I could break down this wall of not blogging.

Image

It is simple – “10 minutes” and “Now”. I even have this written down on my monitor at work. When something feels too big and I have trouble getting started, I try breaking it down into steps each of which would take 10 minutes. And then I start doing them NOW. Believe it or not, it has been working and a proof point is this blog post. I just opened WordPress and started writing.

Try it for yourself. Whether you are a software product manager procrastinating on starting a requirements doc for a complex feature or you are a painter wanting to start a painting, break it down into “10 minute” chunks and start on it “Now”.

10 minutes get over fast and before you realize you are 30 minutes into it. The sense of accomplishment suddenly carries you forward. Agile development methodology is built on this core principle of breaking things down, building fast and shipping often.

Do you agree? Thoughts, comments?

Image: Courtesy of digitalminimalism.com

Agile vs. Waterfall – what is the big deal?

I have been working in companies the last 5 years where we have followed the agile methodology in product development. Shorter sprints, faster releases as opposed to month long development cycles that were common in waterfall.

Here is a guest blog post written by Mike Cudemo of Sparta Systems that explains the differences between Agile and Waterfall product development methodologies in a very simple way. He also explains the benefits of doing agile as a way of increasing the success rate of IT projects.

Seeing is believing.  Agile methodologies are not perfect, but they are three times more successful than traditional waterfall methodologies (source: Standish Group).  Agile methodologies allow end users and stakeholders to visualize their requirements faster and catch errors earlier in the development process.

A waterfall process can be likened to building a house.  An architect translates your requirements into blueprints which only an architect can visualize.  Your first glimpse into reality occurs after the foundation is poured and the walls are erected.   While things can be changed, it is more expensive to change.  Most people struggle to catch problems until the drywall is up and the ductwork and plumbing are in place.  Again, you can make changes if there are issues, however, now it is even more expensive to address.  The waterfall process attempts to “freeze the requirements” after the blueprints are designed.   As you can imagine, this is not reality.  The later you catch a requirements problem (e.g. I want a larger master bedroom closet), the more expensive it is to fix.  In some cases, it is impossible to fix.  You can have the closet, but little Timmy needs to sleep on the roof!

The Agile Method does not attempt to “nail and freeze the requirements” all up front at one time.   It assumes that the requirements will evolve and change as the customer begins to visualize their own requirements.  The Agile Method attempts to build the house by first creating a visual 3D representation of the outside of the house.  This is how it is going to look when you come home from a long day at work.  After the outside look and feel is developed, you attempt to construct the house one to two rooms at a time.   The Agile Method attempts to focus the requirements, design, code and test into iterative smaller development phases.   Essentially, the Agile Method is a series of smaller contained waterfalls.  End users and business stakeholders get to see and experience the system as it unfolds.  Course corrections become more apparent and easier to navigate.

Waterfall processes attempt to minimize and control change.  Agile processes accept the inevitable need to accommodate learning about the real requirements.  End users think in broad strokes; however, we all know the devil truly lies in the details.   Skilled Agile development teams have a clear methodology to guide the process most effectively.  They will select the plot and then develop the look and feel of the outside of the house. Next, they will focus on the 1st floor, and then move to the second floor.  The finished basement will be last, because as we all know, we’ve run out of money by that time.

We find ourselves in the worst economy since the Great Depression.  Many CFOs find themselves in a complex juggling act of cutting operational costs and making technology investments.  CFOs are forcing their CIOs to come up with plans to leverage existing investments, yet develop the capabilities to rapidly respond to both economic growth and competitive changes. Project failure is really not an option, yet according to the statistics, waterfall approaches waste 60% of a company’s IT project budget.

Over 20 years ago, 90% of IT projects failed or under-delivered on functionality. Today, depending on your source for statistics, IT projects fail or under-deliver between 30-70% of the time.   It is better, but far from perfect.  It is clear, that Agile methodologies are at least 3x more likely to succeed.

Agile methodologies are iterative. Understanding is paramount to containing change.  Systems unfold one functional area and set of screens at a time.  An Agile Methodology will not fix a bad project vision, an impossible task, or a lack of skilled personnel.  Properly applied, an Agile approach will catch the poor vision, unattainable goals, or lack of resources early.  IT and application departments must learn that cancelling a project early is actually a win.   Broken processes should be fixed first before they become institutionalized with software or a system.

Companies that employ Agile methodologies and cancel unattainable projects early will thrive.  Their IT success rates will exceed 85%.  Most importantly, they will have more working capital to drive growth, innovate, and increase productivity.

About Mike Cudemo

Mike Cudemo runs the Customer Success Program at Sparta Systems.  The program accelerates knowledge transfer of best practices to our customers to enhance overall business performance.  Mike spent over 12 years integrating manufacturing operations with ERP and value chain systems at Fortune 100 clients, utilizing his expertise in value chain, quality, manufacturing execution and process automation systems. Trained as a systems engineer to analyze and simplify computer systems, Mike has spent a career helping clients understand their core business drivers, simplify the underlying processes, and automate the repetitive, non-value-added tasks which introduce defects and waste.

Importance of sprint demos

In an agile development process, you typically launch new features into production every 2-3 weeks. Before launch, it is important to ensure that all stakeholders get to know about the new features to be released. It is especially important for Customer Support, Training, Translators, Sales etc. to get to know these new features before customers get their hands on them. I have found the best way to do this is via a sprint demo. When I have organized these demos, here are three guidelines I have followed:

  1. All key stakeholders have been invited – marketing, sales, product, customer support, qa, …..
  2. The demo is held a couple of days before the release – stakeholders should have some time to react to the new features and also engineering – in case there are small changes that need to be made (textual changes or other very minor changes).
  3. The demo is done by engineering. This is very key for me. Engineers toil hard to get everything done and it is their work that is being shown in the demo. Given this, they are the best ones to show case what they have built. It also ensures that everything to be released is completed before these demoes.

What are your experiences? How do you do your sprint demos?

 

Understanding Constraints

In the past, I have written what a new software product manager should plan do in the first 30 days on a new job to be successful. If you are planning to start on the right foot at a new job, a key thing you need to understand is constraints. Especially in a startup, during early days when things are move lightening fast, shortcuts are the norm because of constraints. There is not enough money, people and most importantly time. You are trying to put your MVP (minimum viable product) out there, get early success to build upon that there are not enough hours in the day to do things better than you are doing now. 

So if you are a new product manager who walks into such an environment, the last thing you want to do is to criticize the way things are. Instead, spend the time to understand the reasons why things are the way they are. 9 times out of 10, the folks that have been there are not stupid to have done what they have done. The team will be very appreciative if someone takes the time to appreciate what they have done under the constraints they had. I am not suggesting that you be disingenuous and praise something when everyone around you knows it is a pile of shiitake. You have been hired for a reason. If you are hired as a VP of Product, it is probably because things have not been rosy and the company needs a direction. But before you start to rock the cart, first find the reason for the current madness.

Another occasion where understanding constraints becomes valuable is when you are making a business case for something. Sell the idea first (before you ask for resources), make sure there is buy-in and then outline the constraints that will need to be resolved if the idea needs to succeed. This could be asking for more people or funding.

Thoughts? Do you agree? What can you share from your experiences?

Image: Courtesy of scmep.org

3 mistakes to avoid in a Product Manager Resume

I have been reviewing tens of resumes lately as I have been looking to hire a product manager in my group at Care.com. Here are some patterns that I have noticed that makes me to quickly move on to the next resume:

  1. Buzzwords: When I read “Builds and manages relationship with customers to smooth transition from legacy, fragmented business processes and systems to streamlined global product development processes enabled by enterprise technology implementation that improve efficiency of new product delivery and sustaining engineering“, I have no idea what you are talking about and I move on very quickly to the next resume.
  2. No quantitative metrics: If I see no metrics or results achieved based on what you have done, I get no sense of whether your efforts were successful or not. Instead of saying “Launched a customer visit program for direct reports”, add more meat and metrics. Tell me what happened as a result. Instead, it is more useful to read something along the lines of “Developed an on-site customer visit program for direct reports that resulted in 200 visits/year. Improved understanding of customer product design needs resulted in launch of 5 new products in 2 years for the machine design and consumer design vertical segments.” It gives me context and also a better understanding of your accomplishments. However, never make things up, hiring managers will be able to sniff things out very easily. Trust me, I have seen candidates lie on their resume and it has come out within 5 minutes into the interview.
  3. No white space: Your resume is so full of text with minimal spacing, I as a reader have trouble focusing on something in your resume. It becomes a lot harder to read your resume. Presentation matters, readability matters. You want to stand out, make it easier for the hiring manager to read. Ask yourself this question – “Does my resume highlight my key achievements that will make the hiring manager want to pick up the phone and call me?” You do not have to put in everything you have ever done in your resume, what you want are your key achievements. The nitty gritty details can come in during the interview (if you think it is relevant to mention them). A good friend of mine, who has been a VP of marketing at many companies gave me a good rule of thumb – “1 page of resume for every decade of your experience”.

Thoughts? Comments? What are your experiences as a hiring manager?

Related articles:

  1. 10 job hunting tips for a product manager
  2. 8 traits of good managers
  3. 7 tips to survive a layoff

Customer Visits – Do’s and Don’ts

I attended the Product Camp Boston over the weekend and shared what I have learnt doing over 300 Customer Visits in 10 countries (US, Canada, Japan, UK, Germany, Netherlands, India, China, South Korea, Taiwan).

Customer visits can be the best qualitative method to learn the most about your customers/prospects – stuff you will not learn from surveying them. But this is only if you do them right. Based on experience doing 300 of them in 10 different countries, I would like to share what has worked and what has not.

Here are the slides I used.

I am looking to hire a Product Manager

I am looking to hire a Product Manager who has minimum 4 years of experience doing software product management (mostly consumer) to join my team doing product management for International products at Care.com. Details below. You MUST have 4+ years of experience to be considered. If you or anyone you know is interested, please send me your resume to gshenoy (at} care [d o t) com. 

The international group is small (total of 7), follows an agile development process and is very fast paced. We launched in the UK last month and will be launching in other countries very soon.

Product Manager based in Waltham, MA

Care.com is seeking a highly motivated individual to join its International Product Management team in the position of Product Manager. The individual will be responsible for defining, prioritizing, and overseeing the implementation of features and functionality of Care.com‘s international websites. The ideal candidate must have previous experience developing product requirements for an online, consumer service. In addition, the candidate must be able to effectively manage cross-functional teams of stakeholders throughout the organization.

Specific Duties/Responsibilities:

  • Ownership of product requirements for Care.com’s online product offerings for international markets. This includes the requirements gathering process, requirements documentation, and the ongoing maintenance of requirements as the business context evolves.
  • Working directly with stakeholders throughout the company to ensure that a successful product is delivered.
  • Working with business owners to understand and document the product requirements.
  • Working with engineers to communicate product requirements, make trade-offs, and oversee the product implementation and testing process.
  • Working with marketing to understand marketing plans and strategy and ensure the site and reporting platform support those plans.
  • Working with the member care team to ensure that product support concerns are addressed in the product requirements.
  • Working with the finance team to ensure that any revenue generated from the product is accounted for correctly.
  • Driving cross-functional teams to deliver a product which is on-time and in compliance with the product requirements.
  • Assist Director of Product Management in creation of product roadmap for international products.

Skills/Experience Requirements:

  • 4+ years of product management experience REQUIRED.
  • Experience working for a company/organization that develops and runs an online service, preferably a consumer-oriented service.
  • Experience working directly with customers in doing market research and usability testing.
  • Experience writing product requirements documents and functional requirements documents. This includes experience developing wireframes using tools such as Balsamiq or other similar tools.
  • An understanding of Information Architecture and a passion for defining a highly-usable online experience.
  • Demonstrated ability to manage cross-functional teams, solve complex problems, and produce high-quality results.
  • Knowledge of and experience with reporting requirements of an online product.
  • Experience working in an agile development environment.
  • Ability to roll up the sleeves and work in a fast-paced, start-up environment.
  • Excellent oral and written communication skills.
  • Ability to work independently and in a team environment.
  • Willing to travel internationally as required to meet with customers (travel expected to be less than 5%)

Education/Other Pre-Requisites:

  • BA/BS degree in engineering or related field.
  • Knowledge of German, French or any other languages considered a plus.

 

Follow

Get every new post delivered to your Inbox.

Join 1,818 other followers

%d bloggers like this: