Continuous Development

Recently, I began re-reading Kevin Kelly’s 2016 book The Inevitable, which takes an insightful look at twelve technology trends taking hold in today’s world and shaping the future. While reading it this time around, I’m more attuned to the fact that Kelly asserts human behaviors are evolving in reaction to the technologies that are becoming more and more ubiquitous. However, as product managers, we must ensure innovations are developed around people and their needs before all else.

According to Kelly, technology is advancing at a pace faster than most people can understand or fully utilize, and networks are enabling technology to build upon itself with less human intervention or human understanding required. Kelly writes in The Inevitable, “We are morphing so fast that our ability to invent new things outpaces the rate we can civilize them.” 

Yet, has technology evolved to become an entity acting separately from its human inventors? 

While Kelly’s trends astutely identify a trajectory for progress, and his optimistic vision of the future ranges from pragmatic to truly inspiring, it is easy to lose sight of the fact that technology cannot evolve in a vacuum. 

Technologies should advance in the service of unique, individual human needs: to maximize freedom, to foster shared understanding, to optimize the quality of life, and to realize human potential.

At a micro-level, we as product managers must guide our own innovations through the lens of human development, not just of technological or organizational advancement. We need to develop deep understanding of the people who use our products and enable our teams’ actions to be placed within the context of peoples’ common motives. We must ensure empathy for individuals is always a leading factor behind our decisions. 

Although many techniques could facilitate better understanding of people’s needs and behaviors relative to a technology or trend, a particularly useful strategy is marrying realistic user personas with specific jobs to be done for which your solution can add unique value.

User personas describe an archetype of a person who is targeted as either a desirable user of your product or a current user of your product. Personas represent cohorts of people that share common characteristics, behaviors, and motives. They are expressions of data, typically formed by combining quantitative feedback (hard numbers) with qualitative feedback (responses to open-ended questions). Yet, their outcomes can be very personal and there are many ways to create effective personas.

An analysis of customer jobs to be done asks managers to take their personas a step further, to define and prioritize key needs that each persona must satisfy, along with the various ways that they are meeting that need. Identifying a customer’s jobs to be done involves taking into account all of their alternatives and fosters an understanding about how your products could be developed to fulfill the same or a similar need. They also provide benchmarks for your product to objectively improve upon those alternatives and add insight into a person’s full experience. 

For Harvard Professor Clayton Christensen, jobs to be done “allows me to go to that second level.” According to Christensen in a 2016 HBR podcast, a product “can’t provide experiences unless [it] understands the fundamental job...[and acts] kind of like a North Star, and my innovators in my company can do all of this work, sometimes our of the line of sight of executives. But if you have that North Star, the job to be done, they will collectively do a better job in innovating.”

Kevin Kelly poses a call to action in The Inevitable:

We are marching inexorably toward connecting all humans and all machines into a global matrix. This matrix is not an artifact, but a process. Our new supernetwork is a standing wave of change that steadily spills forward new arrangements of our needs and desires. The specifics...hinge on the crosswinds of individual chance and fortune...We stand at this moment at the Beginning. The Beginning, of course, is just beginning.

Nearly 17 years ago, the Agile Manifesto set forth principles for an iterative, adaptable means to deliver valuable technology to market. Since that time, Agile has evolved into an umbrella methodology, sparking iterative development frameworks such as Scrum, Kanban, and Extreme Programming; and amplifying the impact of iterative frameworks in related fields such as Lean Startup and Design Thinking. Arguably no philosophy other than Agile has played a greater role in facilitating “software eating the world”.

While Agile thinking has enabled modern, high-growth companies to quickly build products that compete with traditional alternatives, established companies remain perplexed that Agile methods within their own environments too often fail to bring their own disruptive innovation to market. 

In The Startup Way, Eric Ries underscores how an Agile mindset is at odds with traditional organizational design. 

According to Ries, established companies tend to structure their organizations based on the legacy of Alfred Sloan’s “decentralization with coordinated controls” and Scientific Management. While Scientific Management’s rigorous forecasting can facilitate efficient production at scale and cultivate accountability, it discourages unpredictability and experimentation. 

Through the lens of Scientific Management, Agile looks an awful lot like a process whose purpose is to increase efficiency or predict timing of software delivery, not an adaptable approach for teams to continuously develop valuable technology and adjust quickly to customer needs. The Agile mindset is difficult to capture on paper, which makes it challenging for corporate organizations to implement within familiar frameworks.

As a result, too many companies institute an Agile process, not an Agile mindset, spending enormous budgets to revamp large scale processes without committing to shifting core beliefs surrounding their product organizations.  

It seems counter-intuitive to put effort behind delivery transformation initiatives that require product teams to comply with complex “agile” rules and milestones when the very nature of the Agile mindset is about committing to focused learning and embracing uncertainty. 

Agile's iterative frameworks exist to find and build a minimum viable product as quickly as possible, learn from it’s successes and failures, then iterate. Process alone may standardize schedules and promote efficiency, but it misses opportunities to uncover meaningful products and features through repeated hypothesis testing and measured failure. Without organizational structures in place that promote all forms of product discovery - including fast failure - Agile and delivery transformation are simply buzzwords.

Janice Fraser offered some truly transformational advice to leaders of established companies in her talk at Mind the Product San Francisco Conference in 2017, which can be found above.

1. Value small, fully dedicated Agile teams and hold them to different standards than other functions. 

2. Invest in them as if they were a startup seeking funding, rewarding results with autonomy while limiting potential for loss. 

3. Openly discuss specific learning that results from their failures and incorporate across the organization. 

4. Provide runway for their product’s long term impact, as opposed to repercussions for missing short term estimates. 

Management guru Peter Drucker famously advocated for ignorance as a path to sound decision-making. According to Drucker, his greatest strength was “to be ignorant and ask a few questions”, rather than providing answers. “Ignorance is the most important component for helping others to solve any problem in any industry.”  

For product managers, Drucker’s advice is vital to success, particularly for those of us responsible for complex, evolving technology products. Why? Because the overwhelming majority of your product’s users are ignorant of the technical details, and they simply do not care. Details do matter, but some far more than others. As a tactic, ignorant questions are an effective way to channel the perspective of a user (or a stakeholder) and bring a complex conversation’s focus back to the level of “so what?”

Yet, too often Drucker’s advice goes unheeded and this tactic is misunderstood as a sign of weakness.

Great product managers must be in the habit of asking very simple questions, not solely for a specific detailed answer, but rather to uncover the more meaningful causes which result in that answer.

Great product managers must seek deeper meaning behind the current detailed answer’s rationale or implications on a customer’s jobs to be done.

Great product managers are also aware that today’s detailed answers too often expire or prove invalid before the tomorrow defined in a roadmap can become realized. 

A product manager is best suited to lead his or her team by discovering rationale for a specific technical choice, or principles being exercised by a question’s outcome. 

In short, great product managers must be comfortable being ignorant of details, but uncomfortable not knowing why those details matter. They must be able to ask questions that uncover factors driving today’s answers, then put them in context of customer impact and the product’s long term value to those customers. They must enable the team to frequently adjust the path forward without regret or ego in order to deliver the most valuable features.

At this time last year, I suggested that we each pursue stated and unstated goals.

Admittedly, many of the goals that I had set did not get accomplished to the letter, nor did I consistently track them throughout the year as suggested. The reality of falling short in both process and outcome can be disappointing, but progress that was made pursuing those goals yielded significant achievements.

 - Charitable donations and acts were done every month.   - Well over 100 workouts occurred.  - Dry January 2016 was a success, inspiring Dry January 2017.   - Several fantastic and thought-provoking books were read.   - I marginally upskilled those coding chops to launch a responsively-designed personal website. 

These outcomes are incredibly encouraging. However, my happiest and proudest moment occurred outside last year’s explicitly stated goals when my fiancee said “yes”.

And in retrospect, this says everything about achieving goals.  

Regarding the stated goals, I focused and acted upon each during relatively brief, yet intense periods. They were discrete, compartmentalized projects.

As for my relationship, my fiancee and I have loved one another and supported each other’s pursuits consistently, every single day throughout the year. This relationship is a lifestyle.

For those stated goals, I hacked together a series of short term habits based on achieving positive outcomes.

For my relationship, I formed a long term habit based on love and shared values.

Aristotle is often attributed with saying “We are what we repeatedly do. Excellence, then, is not an act, but a habit”.

Regardless of who actually provided this insight, the consistent actions that we habitually take help us realize excellence; personally and professionally. 

So how can people succeed in developing lasting habits?

Blogger Gregory Ciotti offers scientific research and goes into depth about methods for developing habits and helping answer this question. To summarize, after identifying a macro goal to pursue, the keys to committing to a lasting habit are in thoughtfully removing friction from the process of action, and in quickness to forgive ourselves when we go astray. 

“Identify where exactly ‘getting started’ falls apart for you and try to create shortcuts so that the uncomfortable moment is lessened...  some startlingly simple advice is to just focus on the total days you’ve done your habit, rather than the fact that you broke the chain.”

I could not agree more, and in 2017 plan to build on the achievements of 2016 by thoughtfully removing friction points and take continuous action toward becoming a stronger product leader, more capable coder, and simply a better man. 

Goal-setting is a common, but miraculous aspect of human nature. Whether aware or not, each of us set goals every single day and are maniacally driven to reach them. 

Get out of bed. Arrive at work on time. Reach your deadlines. Take the kids to soccer practice. Walk the dog. Eat a warm dinner. 

If you consistently fail to reach these goals, real consequences await. You could lose your job, hurt your family, wreck your home, or starve. You could consider each of these goals mundane tasks, as really they comprise what most people would consider “being busy”. 

However, “being busy” is the number one reason Americans give for dropping their often loftier, more inspired New Year’s Resolutions at this very time every single year. According to a study in the Journal of Clinical Psychology cited in the article New Year’s Resolutions by the Numbers, 45% of Americans make Resolutions, but 1 in 3 who do cannot make it through January.

So, in my view, too many people are trading their “be a better, stronger, more balanced person” goals for their “wake up, get dressed, pay the bills” goals.  

Few would argue against the importance of goal-setting and why pursuing ambitious goals are vital for leading a fulfilled life, but successful people don’t just set goals, they reach goals. 

In the oft-quoted 1937 classic Think and Grow Rich, Napoleon Hill suggests that people record--in writing--their specific goals with a plan for achieving those goals, then re-read them every day. 

Needless to say I have employed the assistance of a trusty whiteboard to take Napoleon’s advice to heart. Among the goals I have written on this whiteboard for 2016 are:

- Save over 30% of my income. - Donate to charity at least once per month. - Work out for at least an hour 100 times. - Drink alcohol less than once a week and participate in a Dry January. - Begin teaching myself to code in the MEAN stack by studying 150 hours. - Finish reading at least one book each month. - Write at least one blog post each month.

Yet, I believe the ability to reach these goals can be dramatically improved by using a technique from the field of management science: performance tracking. 

Performance tracking is the process of first identifying key performance indicators, or numbers which help you measure the success of an initiative, then recording results regularly, and finally evaluating the choices and behaviors which yielded those results. 

For me, performance tracking my goals has taken the shape of a spreadsheet.

Recording not only goals but regular progress toward those goals using concrete data, helps break my actions down onto a daily level and is identifying trends in my habits that I otherwise may not have known. The bottom line is that honest performance tracking is making me accountable to my own goals, and making them more attainable. 

Public speaking comes in many forms: speeches to executives, teaching a class, presenting a product to users, job interviews, etc. 

Most people find spoken forms of communication very difficult. 

However, many people find communication through written word--either reading or writing--far easier.

Why?

In his 2012 essay on Writing and Speaking Paul Graham offers his thoughts on what it means to be a great speaker and what it means to be a great writer. 

Having good ideas is most of writing well. If you know what you're talking about, you can say it in the plainest words and you'll be perceived as having a good style. With speaking it's the opposite: having good ideas is an alarmingly small component of being a good speaker.

I find Graham's arguments provocative and a great reminder of the limits of verbal and written media. 

Just as a speaker ad libbing can only spend as long thinking about each sentence as it takes to say it, a person hearing a talk can only spend as long thinking about each sentence as it takes to hear it.

Graham, throughout his essay, implies that complex ideas are best relayed in print while only the simplest, highest-level, motivational arguments can be effectively relayed verbally.

Grahams implied suggestions align with the explicit suggestions Kathy Reiffenstien makes about the appropriate level of detail in a professional speech in her blog Professionally Speaking.

BEWARE TOO MUCH DETAIL

Drowning in detail is a surefire way of getting into trouble in an executive presentation.

Senior level executives think more strategically than operationally. When considering a topic, they want to understand quickly what the impact is on the big picture or the bottom line without wading through the weeds of specific details. Structure your presentation around high level concepts. Not only does this address the needs of your audience, but it also shows that you are capable of thinking strategically. Be sure, however, to have lots of facts and supporting data ready so you can supplement with examples, figures and analysis when your audience wants them.

Pay close attention to your audience's body language and questions that may suggest they want more or less detail. Being flexible and responding quickly to their needs is the best way to keep your head above water.

My takeaway:

Complex products, projects, code, and analyses are highly technical and therefore detailed by nature. 

Discussing complex technical ideas can be dangerous within the context of a presentation or job interview.

As an introverted person, job interviews can be a challenge.

As a visual and experiential learner, I cannot help but struggle to put my thoughts into words. 

As a detail-oriented and analytical thinker, I cannot help but over-think, over-explain, and outsmart myself. 

How can people like me overcome these challenges to prepare for the next opportunity?

Practice. Preparation. Visualizing future success.

After spending the better part of today investigating GitHub, learning a few finer points of the Bootstrap CSS framework through Codecademy, and struggling to finish a few "easy" CoderByte practice problems, I have resolved to spend the evening reading up on the basics of JavaScript. 

And, based on my research, there is no better guide available than Marijn Haverbeke's Eloquent JavaScript. 

In 20 chapters, Haverbeke presents a wide range of concepts that enable readers to build well-formed programs using JavaScript. Five of those chapters are devoted to complex projects. Each of those chapters is valuable and free, though challenging to fully grasp.

However, the introduction offers words of encouragement, completely essential for me right now. If you are in a similar position, they may be helpful for you as well...

The fundamental rules are typically simple and clear. But programs built on top of these rules tend to become complex enough to introduce their own rules and complexity. You’re building your own maze, in a way, and you might just get lost in it.

There will be times at which reading this book feels terribly frustrating. If you are new to programming, there will be a lot of new material to digest. Much of this material will then be combined in ways that require you to make additional connections.

GitHub is an incredibly powerful version control system and social network for any creative professional--not just developers. 

While the internet offers an abundance of resources to learn how to use Git, many can be incredibly confusing and overwhelming, especially for beginners.

I do not consider myself a clueless beginner, but am still incredibly overwhelmed and confused by how to leverage GitHub's powerful tools.

So where to start today? ReadWrite's two part series from 2013.

Part 1 discusses why GitHub is important to show your work, collaborate with others, and learn from the pros, then gives a few helpful definitions.

Part 2 explains how exactly to utliize GitHub from the command line. 

Now that I've taken an Intro to Javascript course, signed up for a GitHub Account, an muddled through setting up a Linux Web Server on AWS, it might pay to learn how to use these powerful tools. The best way?

Face the fear of a bewildering command line. Dive in. Memorize commands. Figure it out. Make things happen.

I have an exciting Thanksgiving weekend--and 30th birthday--ahead.

The advice of Zed A. Shaw's online book "The Command Line Crash Course". Shut up and Shell.

Why? Because if you want to learn to code, then you must learn this. Programming languages are advanced ways to control your computer with language. The command line is the baby little brother of programming languages. Learning the command line teaches you to control the computer using language. Once you get past that, you can then move on to writing code and feeling like you actually own the hunk of metal you just bought.

Like many people, I have often grappled with feeling as though I have overachieved; that it is only a matter of time until people learn that I am not smart enough or capable enough to have experienced success; that it is only a matter of time until I regress to the darkest reaches of average.

This thinking has, at times, encouraged me to recognize the greatness and achievement in the people that surround me while questioning why they have accepted me into their circles, as friends, as classmates, or as colleagues.

Apparently, this mindset is widespread and has earned the title "Impostor Syndrome". 

In a bizarre way, this  unhealthy, stressful thought process can have some positive impact. It can be misconstrued as a driver to continue learning and growing until you are "good enough" to meet your own high standards.

However, as someone who has worked to call out his own "Impostor Syndrome" and conclude it is no more than a destructive shadow following success, I am gradually coming to embrace my own imperfection.

Luckily, I have good company with this very struggle. Among those who openly admit to falsely accusing themselves of being are frauds: Sheryl Sandberg, Tina Fey, and Seth Godin.

Most of the 21 strategies in Kyle Eschenroeder's article about beating Impostor Syndrome on StartupBros.com are incredibly helpful and empowering.

I challenge you to read and embrace the best of them, just as I challenge myself to do the same.

Come off it.

Accept that you have had some role in your success.

Focus on providing value.

Keep a file of people saying nice things about you.

Stop comparing yourself to that person.

Expose yourself totally.

Treat everything as a business/experiment.

Say "It's just Impostor Syndrome"

Remember: being wrong doesn't make you fake.

"Nobody belongs here more than you."

Realize that when you hold back you are robbing the world.

You're going to die.

Stream of conscious writing

Say what you can do and can learn the rest.

Realize that nobody fully knows what they are doing.

Take action.

Realize that you evolve.

There is no person who you can be other than you.

See credentials for what they are.

Find one person to tell "I feel like a fraud".

Really well-done infographic from code.org. I found the source data even more interesting. 

According to the data the single highest paid undergraduate major in the country was a Computer Science degree from my alma mater, Carnegie Mellon.

Even though my focus was not CS, I find this encouraging. 

With an annual gap of over 100,000 jobs in computing, these skills are both impactful and empowering to learn.

Being wrong and realizing you're wrong are two very different experiences. 

Being wrong feels like nothing. Realizing you're wrong feels horrible. 

Being wrong is a curse. Realizing you're wrong is a blessing.

Why? Through realization, comes knowledge; through knowledge comes growth.  

Only through failure, and the realization that you are wrong, can success be achieved. 

As a product manager, you must be proven wrong: both in the technologies that you bring to market as well as within your organization. 

Bringing failed products to life enables you to learn why an endeavor was unsuccessful and better hone your ability to identify what is truly valuable. 

Failing and being proven wrong within your organization, even if you may look silly in the process or temporarily lose some credibility, can prevent others from repeating the same mistakes and can foster team growth. I believe being proud of mistakes and open to discuss them takes courage and is the sign of a leader.

While this article is about preparing for General Assembly's Web Dev Bootcamp, it offers great conversation about personal growth and goal-setting in general.

The article asks to evaluate your commitment as well as technical skillset. My takeaway: look before you leap, but hold yourself accountable to leap big.

To really succeed in an immersive program, it helps to do a complete self inventory of who you are, and decide how you’ll build upon your strengths on this transformative journey. Here are some questions, resources, and techniques to help prepare yourself mentally, and emotionally, for a grueling but rewarding 12 weeks:

1. Recognize your strengths and weaknesses. 2. Evaluate your learning style. 3. Identify characteristics for success. 4. Research and get inspired. 5. Set goals.  6. Hold yourself accountable.

Great, in-depth, exploration of coder bootcamps today and their potential outlook. 

The growth of coding bootcamps, at first glance however, appears to be limited by their labor-intensive model. An industry analysis by Course Report finds that 43 schools have emerged in recent years and that they have projected revenue this year of $59 million from 5,987 customers, a growth rate of 175 percent over the 2,178 graduates last year.