Zen Product Manager

Kill the noise

admin

Getting the government to help with your product strategy

There will always be finite resources that will often lead to potentially impactful product initiatives getting deprioritized. Fortunately, you can leverage government programs to mitigate investment risk associated with your product strategy.   As a product manager, it’s beneficial to stay aware of these offerings because they can be the difference-maker on whether your product strategy gets the go-ahead or gets shelved.

Some long-standing ones include the Industrial Research Assistance Program (IRAP), which provides funds to enable you to hire people for your initiatives.  Another option is the Scientific Research and Experimental Development (SR&ED) program, which can help offset the costs of hiring people to develop new products through the use of tax credits.

If you’re not leveraging funding programs available to your organization, you could be short-changing your product roadmap.

Balancing security concerns with user experience

Cybersecurity and privacy is a topic that is front and center because of the seemingly endless stream of news about system breaches of well-established companies. It’s not a surprise then that when designing new products and functionality, there is sometimes a tendency to exaggerate the potential risks and, therefore, over-engineer solutions. As a product manager, you must be able to lead your team to an appropriate balance.

As an example, I was once working on a new module that sent a document with obfuscated URL to users. The users would then open the URL on a Smartphone and digitally accept the contract, which would kick off an internal workflow. Much to my dismay, during a technical design session, the team not only designed but implemented a grand solution that was more “secure.”

Instead of providing a seamless experience, we required that the recipient enter a 32 character password to access the document. The long password is tedious enough to type on a computer, let alone type it or even doing a copy and paste on a smartphone. 

The team implemented amped-up security to address two concerns:

Concern 1: Someone can forward the email with the link, and anyone who got the email would have access to the document.

Commentary: Ignore or a moment that the password was included in the exact same email as the URL, in our context, forwarding an email was a legitimate use case as they may have had to send to a colleague or supervisor. Furthermore, there’s a precedent set with other applications such as Twitter, where there are no additional guardrails set to prevent a link from being used if it was forwarded. In the screenshot below, you’ll see that I sent a reset password link from my one email to another email, clicked on the link from my work email, and was able to change my password.

Concern 2: Using a GUID is not real security because you’re just obscuring the link. 

Commentary: Google Photos security is all around obscuring the URL and not requiring an explicit password (they use this same approach with Google Drive documents). You can read more about it here. An essential part of the article is the following:

So why is that public URL more secure than it looks? The short answer is that the URL is working as a password. Photos URLs are typically around 40 characters long, so if you wanted to scan all the possible combinations, you’d have to work through ¹⁰⁷⁰ different combinations to get the right one, a problem on an astronomical scale. “There are enough combinations that it’s considered unguessable,” says Aravind Krishnaswamy, an engineering lead on Google Photos. “It’s much harder to guess than your password.” Because web traffic for Photos is encrypted with SSL, it’s also kept secret from anyone on the network who might be listening in.

After a lengthy debate, we concluded that the risks were minimal because the URLs were 40 characters long, the maximum # of unexpired URLs was 5,000 at a time, and traffic was SSL.

Security and privacy will and should continue to be an essential consideration when building a product, but as a product manager, you need to be able to get your team to go through a thought exercise to:

  • Test their assumptions on risk and determine whether they are real risks or just perceived risks.
    • If the threat is deemed real, then design the feature or product with the user in mind and avoid transferring the problem onto the user (e.g., force the user to enter a 32 character password on a SmartPhone.)
  • Go through a pros and cons exercise to assess the available options as a team (dev and product) before moving to implementation.

Consultants moving into Product Management

I connected with an MBA candidate with a management consulting background who wanted to get into Product Management.  It’s unfortunate but the first thing that came to mind was the subtitle of the book “House of Lies.”   After I chuckled for a bit, I got back to the topic at hand.

House of Lies

After probing to better understand his background and motivations, it was clear that he’d have an uphill climb for a variety of reasons.

Background

  1. The consulting was focused on digital transformation (Admittedly, I don’t know what that actually means).
  2. His output was reports and presentations on how the company could transform but there was no execution.
  3. He did not have experience in development or working with developers.
  4. What he liked most about product management was defining strategy…
  5. He’s working on his *cough cough* MBA…

There are three potential paths to get in:

  1. Find an industry that he learned most about especially during his consulting days and position himself as an expert.
  2. Try some side hustles where he can get experience bringing products to market, working with developers, and analyzing results.
  3. Get the skills to start at the bottom in a target company or industry.  The role may be customer support or software implementations. 

If you’re interested in getting into product management, with background described, be prepared to take an indirect route but hope for some luck.    As the saying goes, the harder you work, the luckier you get.

Choice Architecture in UX Design

I recently revisited a book I read a few years ago called Nudge by Robert Thaler and Cass Sunstein, and it hit me that the concepts of “Choice Overload” and “Choice Architecture” are very relevant to building software.

Choice overload

  • Behavioral economists have shown that in some instances presenting consumers with many choices can lead to reduced motivation to make a decision and decreased satisfaction with choices they end up making.

Choice architecture

  • This concept revolves around the idea of designing options in a way that leads consumers towards desired behaviors without limiting choice.

My takeaways in the context of software are that:

1. Offering too many options may result in poor user experience in addition to adding complexity for things that may only be used by few customers. As such, we need to be very deliberate about which options we provide to users.

How am I supposed to use this? Thanks for the example, Des Traynor (https://vimeo.com/81544164)

2. When designing features, do it in a way that leads users to make a decision that we –as experts in our industry — believe is optimal.

Just some food for thought. If you want to learn more about it but don’t want to read the book, check out: https://en.wikipedia.org/wiki/Choice_architecture

How do you define done?

It’s not uncommon for pseudo scrum teams to not have a precise definition of what it means to be DONE. You may have a developer thinking that a feature is “done” once the functional development is complete, but when QA gets to it, they’ll have to raise necessary things like, why is it so slow, or why is it not secure. Such a disconnect will inevitably lead to a long and painful back and forth, and the product owner must then make a trade-off decision to make the release date (i.e., choose the best of the worst options).

The following are some approaches to making sure that the whole team knows what the Definition of Done is:

  1. Define what Done means in your context (this might be an obvious step..but just in case). The Scrum Alliance has many articles on how to do this, but some basic ones include:
    a. Code complete
    b. Unit tests run
    c. Peer-Reviewed
    d. QA tested
    e. Product Owner Reviewed
    f. Follows FURPS
  2. Create posters and put them up on walls around the development area. Putting up such signs may sound hokey, but it works.
  3. Create a “Done” dashboard. In cases where you have a release plan, you can create a Dashboard with themes and use two colors, Green for Done and Red for Not Done.
Here is a basic dashboard in PPT, but you can use any tool like post-it notes on a wall. The whole point is to make progress clear.

Although setting a definition of done may sound odd, it’s a valuable tool to reduce ambiguity, especially in newly formed scrum teams.

Product Management and the MBA

I’m old enough to remember the commercial depicting an MBA who couldn’t send a FedEx package:

I found it funny at the time, and I still do even though I ended up getting an MBA. I decided to pursue B-school cause I had plateaued in my career. I had done an undergrad in a business technology program, and I had always envisioned working more on the strategy side, but up until then, I had been working in technical support and professional services —basically supporting and implementing products created by someone else.

So after I finished, I was so stoked cause I got a Product Management role. Score one for the MBA! Unfortunately, I got a rude awakening. I thought all those case studies and frameworks I learned at school would help me kill it, but in reality, I ended up getting killed cause I was drowning while being pulled in what felt like a million directions:

  • I need the requirements now!
  • the button should go here and why is it that color?
  • how should we position this with the customer?
  • the competitive deck is not up-to-date!
  • there’s a deal, and we need this feature, how can we get it in???
  • I need you to do a demo is 20 mins… and on and on and on.

Years later, a PM I had brought on lamented that the MBA didn’t prep him for the realities of product management. As I reflected on my journey, I was able to see how it helped shape my approach to problem-solving. However, as weird as it is for me to say, if you’re early in your career and contemplating product management, forget the MBA and find ways to get into the school of hard knocks. Build up other vital skills like how to gain credibility with development, empathize with your buyers and users, and navigate organizational complexities.