Skip to content

Change your scope

In 1989, Caroline Paul became one of only a handful of women ever to become a San Francisco firefighter. Paul set out on an undercover mission to uncover sexism in the department. Her goal was to change the world by broadly exposing injustice through a documentary.

However, Paul passed the entry exam and found no evidence if discrimination in the process. She decided to put aside her Stanford education and the expectations of her parents to pursue the adventures of public service.

She spent 13 years in the San Francisco Fire Department, and touched untold number of lives during her tenure.

You see, Caroline Paul wanted to make an impact, but her scope was wrong. Instead of broadly exposing injustices and driving for macro-level change, she made a direct impact on the lives of individuals at perhaps the most vulnerable moments of their lives; delivering babies, administering CPR, responding to gunshot wounds.

I have not read it, but Paul chronicles her time spent in the San Francisco FD in her memoir, Fighting Fire (affiliate link).

Categories: Personal, Stuff I Like.

iPad Mini

I have an iPad 2 which I stood in line at the Apple store to purchase the day it launched. I loved my iPad, but it was a pain to use when reading or watching video in bed, mostly because of the weight.

So my wife got me a Mini for my birthday which has essentially the same hardware specs as the iPad 2 – same resolution (1024 x 768, not retina), memory (512Mb), processor (A5), but just a fraction of the weight. Of course the display is only 7.9″ as opposed to the larger iPad display, but my eyes are okay with it so far.

If I hold the Mini in portrait orientation I can thumb type very effectively. I never did use the split keyboard much on the iPad 2, never could get a good feel for it as it’s not as if I was typing on a true split keyboard where my fingers rest on the home keys. On this point, my Android-using friends (I’m looking at you, @jspad) remind me that they don’t need to type with two hands because they use Swype. Touche.

I tried to take notes on the mini in a business meeting where lots of note-taking was warranted. It was not a good experience. If you need to generate a lot of content, this is not the device for you. Although, neither is the iPad 1, 2, 3 or 4, however, I acknowledge that using an external keyboard made this easier for me on the 2 and would probably help out with the Mini. For those scenarios I’ll just stick with my MacBook (or whatever laptop I’m using) from now on.

Overall, I love my new Mini because of its compactness and comparability in power to the iPad 2.

Categories: Stuff I Like.

Intrapreneurship: A discussion with Ash Maurya

Last week we had the opportunity to meet with Ash Maurya, author of Running Lean (affiliate link). In his book, Ash provides tactical guidance for the customer development and market validation processes popularized by Eric Ries in the Lean Startup.

The Lean Startup methods are fantastic, but we aren’t a startup, so we wanted to focus on intrapreneurship: driving value within a large corporation through risk-taking and innovation.

In recent years, product teams have adopted agile approaches and the “lean” mentality: start small, iterate, learn, tune, scale. However, the pace of adoption of these concepts on the business side – marketing, sales, services, support – typically lags that of product. It turns out that the business’s primary interest is in protecting the status quo; the curent revenue and profit streams, not driving risky new innovations into the market. A thorough, scientific accounting and full understanding of any perceived disruption to the steady state is required for the business to get behind new product innovation.

On the surface this seems like a reasonable expectation, but there is significant statistical evidence that knowing exactly where we’re going and having a detailed plan is much less important than our ability to embrace uncertainty by trying many small experiments. For more on that topic, check out the idea of convexity vs. understanding by Nassim Taleb, author of The Black Swan (affiliate link).

While the merits of planning vs. experimenting are worthy of further discussion, this article is about ideas we discussed with Ash for working more closely with the business units to embrace the lean mindset, iterative discovery, and in-market learning. We noted several practical strategies for “de-risking” the process of in-market validation in partnership with the business:

1) Validate your business model hypothesis within the smallest segment possible

Market risk exists when there’s uncertainty about building a viable business. We can address market risk in stages. When we talk about the “next generation” of that business or changing the business model behind it, we generate fear. And fear often manifests as political posturing and defensive, protectionist tactics.

We should search for a learning ground that is acceptable for both the business and the product team. For example, if we desire to replace the flagship product because of technical limitations and risk, we should choose a small corner of the existing installed base to test something new. We must achieve small successes to gain the trust and demonstrate the value necessary to take on successively larger amounts of risk.

2) Focus on one objective at a time, e.g. existing or new customers?

Using experiments and innovation accounting to “define, measure and communicate progress” is key (see How We Use Lean Stack for Innovation Accounting). To be effective these efforts must have focus. For example, we may be working on a replacement strategy for an existing product, but we also believe that new product will allow us to attract new customers. The experiments and resulting outcomes are discrete and we should test them independently.

Using Ash’s Lean Canvas approach, we can model the opportunities, assumptions, market segments and implications independently and design tests relative to each set of realities. Compartmentalizing these efforts allows us to focus and avoid muddling results of our discovery in each area.

3) Win early adopters within the business

Just like we find early adopter users, we have to find early adopters of the vision within the business. They will need to take a leap of faith with you, and as can act as champions within the business as we achieve incremental success. As successes grow, we can expand the circle of business early adopters until the product/innovation is ready to become mainstream.

4) Do all of this very quickly

The speed in which we execute matters. As a best practice, new ideas and market opportunities should be defined and validated within 3-6 months. This is not only a good, Lean practice, it’s the key to building trust within the business. When market validation activities 12-18 months or more, folks get impatient and concerns rise. Questioning investment levels and applying pressure for plans and checklists doesn’t help matters, because until there is in-market validation, any and all plans regarding the trajectory of a business are purely speculative.

In fact, best practice may be to launch a charter program in 3-6 months before asking for any formal business unit buy-in. It’s my opinion, however, that having someone from the business participate in the experimentation is absolutely critical to long-term success. But they must be versed in the lean mindset and approach the process in an entrepreneurial way.

In conclusion…

It was a great opportunity to talk to a leader in the field of lean methodologies. The discussion further affirmed for me that the lean approach can work inside an established business if we do the things I mention above. The business craves knowledge and understanding and the best way to learn and achieve those assurances is in small, digestible chunks. We will never get around the fact that there is no crystal ball. The future is inherently uncertain. The business and product innovation teams must share this understanding and build plans together that encourage rapid learning through experimentation in market instead of inside-out plans that assume specific outcomes.

 

 

 

 

Categories: Business of Software, Culture, Innovation, Product Market Fit, SaaS.

What really makes a team agile?

I hear and read a lot about the zen of agile, scrum, Kanban, etc. these days (actually for the past decade+). But I don’t buy in to the theory that time boxes, daily stand ups and sprint reviews make a team agile. What matters infinitely more is how we engineer software and release processes to shorten the feedback/response loop.

Here are a few questions to test a team’s agility:

How long after releasing code do you get user feedback?

Do you generate and monitor real-time business and usage analytics for your product?

How quickly can you respond to user and analytical feedback with product updates?

Can you release whenever you want to?

Is your testing automated?

Frankly, it matters less what internal processes you use to drive the work the team does. I say whatever works for the team which is likely to include best practices from multiple methodologies.

What matters more, and really makes teams agile, is an ability to ship and iterate quickly based on real user and market feedback.

Code that’s checked into version control but not in the hands of users is like inventory sitting in a warehouse. Hidden costs abound. A tight feedback and response loop supported by strong engineering practices is the hallmark of a truly agile team.

Categories: Agile, Product Development.

Everyone interacts with users

I just spent two days with 45 users representing 17 customers along with several colleagues including some of my engineering team, and I was reminded that when engineers interact with users, fantastic things happen. Problems are understood deeply, clearly, and solutions are conceived.

When software companies get big, employees are organized by function. While necessary on one hand we do a terrible disservice to users when divide responsibilities. For instance, product managers are responsible for understanding the user problems they want to solve, designers are responsible for prototyping solutions, and engineers are responsible for crafting the final product.

In this process, there are multiple handoffs resulting in lost fidelity as we transition from problem definition to solution. Wouldn’t it be better if the engineer, designer and product manager were interacting with the user firsthand?

In my experience, some of the best design insights come from engineers, value definition is clarified by clear-thinking designers, and product managers can drive key technical decisions. In a traditional organization with rigid role definitions, these occurrences would not be possible. Everyone looses, especially users.

So my thesis is this: If everyone in your org is interacting directly with customers in some way, my guess you are building better products faster. If not you’re losing productivity and innovation opportunities that can be gained by applying the best and brightest minds in the building directly to customer problems

Update: Case in point, Just ran across this article on British Airways launching a program to put tech staff on flights with customers.

Categories: 100 words per day, Design, Product Development, Product Discovery.

Unsubscribing

This morning I unsubscribed from a bunch of email lists that I’m even not sure how I got onto.

If you’re an email marketer, listen up: If I seek out the tiny “unsubscribe” link at the bottom of your email, please assume that my intent is to unsubscribe from all emails. I don’t want to decipher your form, re-type my email address, or manage my profile.

Out of seven, there was only one that allowed me to unsubscribe with one click on that tiny unsubscribe email link. Kudos to them.

Creating a great user experience means not overlooking any customer or prospect interaction – even the unsubscribe. If you don’t respect my time when I’m not your customer, will you respect it if I become one?

Categories: 100 words per day, User Experience.

Communicating value

Product managers have the challenge and privilege of associating the work of engineers to the value created for customers and users. But all too often, we bombard our listeners with details that aren’t relevant to our story.

Often times organizational and personal value is derived, like this:

Thanks to the Acme Software, I can do in three days what used to take me three weeks. As a result I get to focus on activities of higher value to my organization.

– or –

Because of the new capabilities of Acme’s software, I was able to spend time with my wife and kids over the holidays even though I had looming deadlines in December.

But sometimes we communicate like this:

The new release of Acme’s software allows users to process invoices and easily run quarterly reports.

Really? That’s great! (not really)

Some product people are primarily responsible for driving customer discovery and development as product owners, while others are more focused on taking a product to market. Some of us do both, and if you’re in a startup environment you might even be coding as well. We have to get ourselves out of implementation mode when presenting a product’s value to the market and stakeholders.

I find it especially helpful to have one on one discussions with users who are willing to share personal stories about working with your product and the value they’ve derived from it. These are also known as references.

It’s not what your product does, it’s the impact it leaves behind that makes it special. Are your stories about features or impact?

 

Categories: Product Marketing.

Navigating Chrome tabs with the keyboard

I’m almost embarrassed to publish this, but I just learned to navigate tabs in Chrome with keyboard shortcuts thanks to this Google Group post. From the post:

  • Next tab (from current): CTRL + Tab (mac) / CTRL + PgDown (Win)
  • Previous tab: CTRL + Shift + Tab / CTRL + PgUp
  • Specific tab: CMD + 1 to CMD + 8
  • Last tab: CMD + 9
  • Open previously closed tab: CMD + Shift + T (thanks, @willia4!)

This will literally save me hours over the next few years of my life. Can’t believe I hadn’t Googled it until today…

Categories: Productivity.

This week’s Heroku debacle

A blog post went viral this week and uncovered an issue in PaaS provider, Heroku’s routing mesh, which has caused a significant degradation of Ruby on Rails app performance. Essentially, over the past three years Heroku moved from “smart” to “random” web request routing among an account’s “dynos”, Heroku’s processing units. Each dyno runs about $35/month.

The change in architecture, which is explained in detail here, is only a portion of why Heroku is catching heat. Here are the real reasons:

Same cost, less value

First and foremost, there have been no reductions in price for the net reduction in capacity provided by the service. This is especially frustrating to the community at a time when other PaaS providers like Amazon Web Services (AWS) continue to lower their prices. Heroku’s platform leverages AWS in its architecture. Over time, users were purchasing more dynos for their accounts with diminishing returns. Each additional $35 dyno does not provide $35 in value.

Appearance of deception

Second, Heroku boasts robust monitoring tools that allow you to see the performance of your applications across many layers of their architecture. However, the monitoring tools provided by Heroku and New Relic don’t reflect the area of latency caused by random request routing. For a highly sophisticated platform provider, this oversight comes across to the community as deceptive rather than as an oversight.

Lack of coherent communication

Finally, there was no communication to customers about the change, and no consistent and coherent documentation. In fact, documentation around Heroku’s site was confusing and contradictory. Again, the appearance of deception.

Response

Heroku is responding openly and humbly, which is the proper way to handle the situation, but there are many who don’t think the responses go far enough. They want monetary reparations as well. I’d guess Heroku is considering concessions quietly by necessity as they are part of a publicly traded company and any concessions could have an impact on current and prior period financials of the company.

The whole debacle reminds us that the lack of transparency over time can cause much larger PR problems for companies than the issues themselves. Individual customers have the platform to tell their story and initiate change.

Categories: Business of Software, Platforms, Technology.

Using Font Awesome with Rails asset pipeline

To use Font Awesome with a Rails app and the asset pipeline, add the following lines to config/environments/development.rb

In the font-awesome.css file, just reference the file name of each font file (rather than referencing the containing directory):

Thanks to Ashitaka for this stackoverflow response.

Not sure if this will work with Heroku, will find out shortly.

Categories: Rails Notes.

© Copyright Jay Nathan, 2010-2013