Category: software development

Getting out of a slump 

If you are working on something important in a large company, chances are a lot more people at going to be involved in this project than you imagined and you have to find a way to engage and align them. I thought I knew this but I did not realise how crazy things can get. I think I almost got depressed working on this new, important project as I figured out how many conversations I needed to have and how many presentations I needed to make to get alignment. Here is a quick summary of how I felt during the last one month working on the project. 

Thursday July 4th: Down and Out

It’s so easy to get yourself down. I am having a hard week because it’s been difficult to figure out product strategy questions while figuring out the politics around it. Stakeholders are asking good questions but I’m just seeing them as roadblocks. I’m also spending every waking moment thinking about clever retorts and smart one liners to put them in their place. Obviously this is not healthy. And, for the first time in my life, I had trouble sleeping two nights in a row. 
So.. I brought out the big guns. I relied on the advice from Tony Robbins, Tim Ferriss and my dad and decided to: 
  • Write 
  • Listen to music 
  • Change my body language to feel how I want to feel 
  • Journal (gratitude, morning journal) : Could not get myself to do this. 
  • Exercise to get the good chemicals flooding in (swam or cross fit every day) 
  • Decided to treat it as my problem to convince the roadblocks and make them allies. 
  • Met an old friend from high school. Had a good chat, good Zin, unhealthy food 🙂 
  • I also decided to blog about my predicament. This was very helpful. 
I have three paths forward now: Engage my team to answer the objections Ask the roadblocks how they would pitch the idea Let my management chain know that I will need help It’s amazing once you do stuff… Depression disappears and opportunities appear. You think about things you normally won’t. You smile. You change your mindset. The nature of the problem changes. Your head reconfigures. Hope this helps you get out of your head and “save your soul” https://youtu.be/0wBDDAZkNtk https://youtu.be/0wBDDAZkNtk 

July 18th: Working through it. In Action. 

Was a really difficult week but rewarding at the end as I was able to resolve conflicts, raise issues as and get stuff sorted out within the company so that we can get good results in the long term. I did not win every argument. I did not get exactly what I wanted. But it really allowed me to hear other people’s points of view. And, a promising future. 

Update August 16th: A fantastic week

Things have gone well since I decided to stay in action and bring all stakeholders along. It prevented internal sabotage. I did have to have difficult conversations in person with some stakeholders but it was all important and necessary. Had I seen these folks as roadblocks and tried to steamroll my way through, it would not have worked. 
Onwards and upwards. 
–Anubhav 

Improving an existing product

Much more has been written on validating product ideas and new product launches than on improving an existing product. A product is only new once. Most Product managers spend bulk of their time on existing products than on new products. A lot of these products are inherited from other PMs who’ve left the company or moved on to other things in the same company. So, how do you improve an existing product?

Obviously, you have to start by defining what “improve” means. New product managers generally think about adding features to an existing product because it’s an easier problem to solve than trying to figure out where the actual problem is in their product. This problem is compounded by the fact that many PMs do not own their end to end customer journeys. This is especially true in large companies where corporate marketing wants to tell the company’s story and not responsible for input metrics like customer acquisition directly. Product marketing runs it’s own ship and generally has to toe the company line on what to communicate. Sometimes your product is a part of a suite of products and only the top few things across the entire suite of products get the company’s attention.

If you inherited a product and are the lead PM on it, here are some of the questions you must ask:

What business objectives are we trying to meet?

  • Increase revenue Greater customer retention
  • Better free to paid conversion
  • Increased profits
  • Increased adoption

Which of these problems does the business want to solve in the product? For example, you can solve the retention problem by calling users that are churning, sending retention based offers outside of the product or really improve the product so that more uses come back.

Similarly, you can get free users to convert through offers or by experimenting with the trial duration or by offering free tutorials that don’t require any changes to the product at all. Or, you could build better user onboarding into the product so that new users perform tasks A, B, C, which you’ve defined as critical to the product. Ask these questions before you start working on the product.

Once the business decides the “what” only then should you move on to “how”. Generally, it is very difficult to quantify the value of a new feature. Not every product has the luxury to run an A/B test for every feature they want to put in the product. Especially when you have already paid the cost of the building the feature. So, it’s important to build as little as possible. Most teams underestimate the cost of maintaining a feature and updating it when platform changes require it. The true cost of a feature should include: Validation Onboarding, Discoverability, Analytics and  Maintenance.

Since feature estimates always go up, so do all the other costs of building a product. 

Read “Four steps to an epiphany” from Steve Blank. It helps you figure out what kind of market you are in and how you should plan your sustaining innovation work.

Sign up to get motr product management tips directly in your inbox.

–Anubhav

Long standing “legacy” bugs or recently “deferred” bugs

bug

At each release or a push to production, we defer a set of bugs and add to our technical debt. Unless you keep aside time for fixing these issues, you will keep adding to your technical debt. This will become an issue sooner or later. But doing this is hard. It is easier said than done.

Setting aside time has been really difficult for me as I’ve tried to chase more strategic priorities with a 2-3 year payoff instead of fixing old bugs. I’ve also noticed that very few bugs that we’ve deferred ever come back to haunt us via user to user forums or through social media and have wondered if it even makes sense to go back and fix these bugs

So… what is the optimal number of deferred bugs or legacy issues that we should fix in a given 3-4 month release? Generally, for highly functioning and customer connected teams, this number is much less than what the product management team feels comfortable with at the time of shipping an update.

This means that product management teams can be stricter about the total number of bugs to reopen for fixing after a release has shipped. I believe that we will get much better results if we let the feature team or “squad” decide which bugs to reopen and fix in their area.

Once we have a list of bugs to reopen, it has not been easy to get these fixed in time for the next release. We’ve tried different strategies like:

  1. Assigning a bucket of bugs to the team and letting them fix the bugs over an 2-3 month period
  2. Prioritizing deferred bugs  and letting the team fix as many as they can within a month after release
  3. Setting aside a 2 week period where the team only fixes bugs in the order of priority of the bugs

We have had the most success with option #3 since it gives a clear goal and time to the dev team to go after these bugs. This said, we still don’t get all of the bugs fixed since fixing long standing issues is not trivial, otherwise we would have fixed them already. Other options lead to teams fixing easier bugs rather than going after the hard, important ones.

Writing effective call to action messages in software

I recently had a to review an important call to action dialog. We had just finished an important feature and wanted to drive its usage. The call to action dialog came up automatically and urged the user to try this feature.  The team had taken two stabs at rewriting it but it was still too long & repetitive. Additionally, it was written from the point of view of the team and not the customer.

Since I have limited writing experience, I started searching for “Effective Software dialog messages” or  “Better messages in software” but did not get good results in both cases. This made me think about the problem differently. I then searched for “Writing effective call to action messages” and found a rich volume of work that helped me re-write this message.

Here are the blogs I found useful:

  • http://blog.crazyegg.com/2013/07/24/call-to-action-examples/
  • http://blog.hubspot.com/blog/tabid/6307/bid/31435/How-to-Write-Call-to-Action-Copy-That-Gets-Visitors-Clicking.aspx

I felt the following rules applied most to us, while these are obvious, they can be hard to do right:

  • Keep it consise
  • Focus on the user’s benefit
    • Designers saved 30 mins a day by using “feature x” instead of feature x is great, try now
  • Eliminate risk for the user in trying this new feature
    • Try it now, you can always disable it from the preferences menu
  • Use numbers, where possible. For example:
    • “Feature X” saved 15% of time spent in doing something in a recent user study. Click yes to try now
    • 11 tools have been revamped to make you more effecient in this release, click yes to try now

I now feel that I should take a class in writing or rhetoric. There are many available on coursera. Let me know if you’ve had a good experience with any of them.

–Anubhav