john gibbon
  • Bio
  • Stanford Class
  • Product Mgt
  • Product Dev
  • Career Resources
  • Blog
  • Talking Product Strategy

Empowered

7/16/2022

0 Comments

 
Picture
  
Recently I heard Marty Cagan speak as part of the McKinsey Product Academy Series. In the past Marty has spoken at my class and I have reviewed his book Inspired, my favorite book on product management.
 
Therefore I thought it was finally time for me to read the book he wrote with Chris Jones in 2021, Empowered. It can easily be used as a reference book when considering any one of a range of topics about how companies create extraordinary software products. However there are a few central themes which I thought would be helpful to describe here.
 
Two of the main messages around creating empowered product teams are:
  • Give product teams problems to solve, rather than features to build. Empower them to solve those problems in the best way they see fit.
  • Leadership is about recognizing that there's a greatness in everyone, and your job is to create an environment where that greatness can emerge. - Bill Campbell
 
Feature vs Empowered Teams (solve customer problems, achieve outcomes):
     A central theme in the book is the distinction between feature product teams and empowered product teams. A feature team implements features and projects (output), and as such isn’t empowered or held accountable to results. In contrast, an empowered team is accountable for solving a customer problem or achieving a specific outcome, and is empowered to do so in the best way they see fit.   

Difference Between Strongest Product Companies and the Rest 

1. Role of Technology (it is the business, not an expense):
     So many companies still have the old IT mindset when it comes to technology. It's viewed as a necessary cost rather than the core business enabler it needs to be. The people who work on the technology teams are literally there “to serve the business." In these scenarios, the product and technology teams are disconnected from the real customers—in fact, they're encouraged to think of their stakeholders as their customers. For strong product companies, technology is not an expense, it is the business.
 
2. Role of Product Leaders (coaching, strategy, managing to results, deep business and product knowledge):
     Most product leaders are responsible for staffing the in-house feature factory, and keeping the trains running on time. The best product leaders are staffing and coaching product teams, creating product strategy, putting strategy into action, and managing to results
  • You need to be very specific when identifying the most important business problems a product team should solve. 
  • Your role as a leader is in helping everyone on the team achieve the competence necessary to solve those problems.
       Product Leaders need to have a deep business and product knowledge (and frequent customer interactions)
  • Data (how the product is actually used)
  • Industry and domain knowledge
  • Business and company knowledge
  • Product operational knowledge (how the product actually works)
  • (most importantly) Users & customer knowledge
     Cagan recommends a minimum of three, one‐hour customer interactions each week. During weekly one-on-ones he likes asking about these customer interactions to see what the product person has learned. He also encourages the product person to share stories of what they experienced during these visits, and then to share these stories widely around the company. One reason for this is for the product person to establish their reputation as someone who has a deep and personal knowledge of the company's users and customers.

3. The purpose of product teams (product managers, product designers, and engineers)
     Consistent with the central theme of the book, Cagan believes that in strong product companies teams are given problems to solve, rather than features to build, and most importantly they are empowered to solve those problems in the best way they see fit and are then held accountable to the results.


Picture

​Importance of Product Vision, Strategy, & Discovery
In empowered product teams:
  • Product vision describes the future we are trying that improves the lives of our customers 
  • Product strategy helps us decide what problems to solve
  • Product discovery helps us figure out the tactics that can actually solve the problems

Product vision keeps us focused on the customer and serves as a North Star 
     It provides the product organization with a common understanding of what we are hoping to accomplish together. A good product vision inspires ordinary people to create extraordinary products. A good product vision provides us with meaningful work.
     When a company has grown to the point where there are multiple product teams—supporting many customers with their constant needs. It is very easy for each product team to get caught up in their own problems and their own work, losing sight of the overarching goal. The product vision represents the common goal and constantly reminds us of the larger purpose.
 
Product Strategy: Based on insights, it is how we make the product vision a reality while meeting the needs of the company as we go
     While product strategy starts with focus, it then depends on insights.  Insights come only after you spend hours studying your data, your customers, the enabling technologies, and your industry. Insights can come from anyone or anywhere – salesperson, new technology, random comment from a customer, or an academic paper. They might pertain to the dynamics of our business, our capabilities, new enabling technologies, the competitive landscape, how the market is evolving, or our customers. The foundation for significant insights is the strategic context found in the company objectives, the company scorecard/dashboard, and the product vision. Insights are both quantitative and qualitative insights; and they need to be shared and communicated.
     Many companies have a stakeholder‐driven roadmap process, where they basically are trying to find a way to “fairly” divide up the engineering capacity across the different business stakeholders.  But by not picking your battles and focusing on the few truly critical problems, most of the product team's work  does not make an impact.
 
Product Discovery finds product market fit by considering value, usability, feasibility, viability (as discussed in Inspired) 
  • Value – will users buy and use it (Product Mgr)
  • Usability – can they figure out how to use it (UX)
  • Feasibility – can we build it (tech arch)
  • Viability – part of our overall business 
(Product Market Fit is the essential component for any successful product.)
     Discovery can’t be done by stakeholders, customers and prospects; they don’t know what is possible and they don’t know what solutions work
     Often customers try to discuss solutions but they really are discussing problems. It is natural for a prospect to try to dictate requirements for features, but a product manager's job is to work to understand their underlying issues and constraints, and then work collaboratively with your prospective customers to determine if there's a general solution that will meet their needs. This form of collaboration is at the heart of the customer discovery program technique mentioned above and discussed in Inspired.
 
​
Picture
Marty (upper right) and the Silicon Valley Product Group look like a collaborative team that knows how to evangelize 

Collaborative Product Teams
     Your company is probably accustomed to feature teams that exist very clearly to serve the business, and it can be difficult to replace them with empowered product teams that exist to serve our customers in ways that work for the business. Your product organization is moving from a subservient model to a collaborative model.
    Part of this is done by product leaders establishing a direct relationship with the CEO (or general manager in a large company) and the other key executives (sales, marketing, service, finance, legal, business development.) The basis of this relationship is for the executives to believe that the product leaders have a deep understanding of the business and are committed to ensuring that the solutions provided will work for the various aspects of the business. This should be table stakes for the product leaders. Beyond that, there are three aspects the product leaders will be judged on: business results, product strategy, product teams
 
All of this may be Tougher in Larger Companies (Evangelism will help)
     Personally, I think Marty’s suggestions seem to be better suited or maybe more straightforward to implement in small companies with more greenfield products. However, Marty does provide at least one key to being a strong (empowered) product leader in a medium-sized to large‐sized company, evangelism.  Evangelism in this context means marketing to your own organization (e.g., product marketing, marketing, and sales). Some techniques used to help communicate the value of your product or what you’re proposing to your product teams, executives, key stakeholders, and investors include
  • using prototypes
  • sharing the customer pain
  • explaining the product vision
  • sharing your learnings
  • giving great demos
  • sharing the credit
  • detailing the market opportunity
  • showing your enthusiasm for your product
 
 
Check out more information from Marty Cagan at SVPG.
0 Comments

Culture Code

11/4/2018

1 Comment

 
Picture
In "The Culture Code - The Secrets of Highly Successful Groups" Daniel Coyle quotes a Harvard study of more than 200 companies which measured the impact of a strong culture: net income increase of 756 percent over 11 years.

Coyle says that culture is a set of living relationships working toward a shared goal. It’s not something you are, it’s something you do. Coyle suggests that what you should do is build safety, share vulnerability, and establish purpose.

Build Safety

Clear signals of "safe connections" generate bonds of belonging or identity.  "We are close, we are safe, we share a future"

Coyle quotes Alex Pentland from the MIT Human Dynamics Lab, “Modern society is an incredibly recent phenomenon. For hundred of thousands of years, we needed ways to develop cohesion because we depended so much on each other.  We used signals long before we used language, and our unconscious brains are incredibly attended to certain types of behaviors. As far as our brain is concerned, if our social system rejects us, we could die”

Pentland’s studies show team performance is driven by five measurable factors:
  • Everyone in the groups talks and listens in roughly equal measure, keeping contribution short.
  • Members maintain high levels of eye contract, and their conversations and gestures are energetic.
  • Members communicate directly with one another, not just the team leader.
  • Members carry on back-channel or side conversations within the team.
  • Membership periodically break, go exploring outside the team, and bring information back to the team.

Other Tips Coyle provides to "Build Safety" include:
  • Over communicate your listening (avoid interruptions)
  • Spotlight your fallibility early on; especially if you are a leader (to create safety). Leaders need to actively invite input
  • Embrace the messenger (of bad news)
  • Preview future connectors 
  • Overdo Thank-Yous (express gratitude)
  • Be painstaking in the hiring process
  • Eliminate bad apples
  • Create safe, collision-rich spaces
  • Make sure everyone has a voice
  • Pick-up trash (shows humility; shows you are serving the group) 
  • Capitalize on threshold moments (that signal we are together now)
  • Avoid giving sandwich feedback (make it two separate processes, people either focus entirely on the positive or on the negative)
  • Embrace fun

Share Vulnerability

Exchanges of vulnerability, which we naturally tend to avoid, are the pathway through which trusting cooperating is built. A series of small, humble exchanges "Anybody haven ideas?" "Tell me what you want", and "I’ll help you" - can unlock a group’s ability to perform.

Braintrust meetings at Pixar and AAR (After Action Review) by Navy Seals can be uncomfortable and candor filled: Where did we fail? What did each of us do and why did we do it?  What will we do differently next time? AARs can be raw, painful, and filled with pulses of emotion and uncertainty

Ideas from IDEO on what questions teams could ask themselves to help improve include:
  • One thing that excited me about this particular opportunity is ….
  • I confess, the one thing I’m not so excited about with this particular opportunity is …
  • On this project, I’d really like to get better at …

Other tips Coyle offers to "Share Vulnerability" include: 
  • Make sure leader is vulnerable first and often. “I screwed up” are the most important words any leader can say. Laszlo Bock, former head of People Analytics at Google, recommends that leaders ask their people three questions:
    • What is one thing that I currently do that you’d like me to continue to do?
    • What is one thing that I don’t currently do frequently enough that you think I should do more often?
    • What can I do to make you more effective?
  • Overcommunicate expectations
  • Deliver the negative stuff in person
  • When forming new groups, focus on two critical moments: the first vulnerability and the first disagreement
  • Listen like a trampoline: not just nodding, but adding insight and creating moments of mutual discovery 
    • Make the other person feel safe and supported
    • Take a helping, cooperative stance
    • Occasionally ask questions that gently and constructively challenge old assumptions 
    • Make occasional suggestion to open up alternative path.
    • In conversation, resistance the temptation to reflexively add value. Don’t immediately say “I have a similar idea” or “this is what worked for me”
  • Use Candor-Generative practices like AARs and BrainTrusts
    • What were out intended results?
    • What were our actual results?
    • What caused our results?
    • What will we do the same the next time?
    • What will we do differently?
  • Aim for candor, avoid brutal honesty: By aiming for candor - feedback that is smaller, more targeted, less personal, less judgmental, and equally impactful - its easier to maintain a sense of safety and belonging to the group
  • Embrace the discomfort (like in AAR) 
  • Align language with action (use the language that is reflective of your culture)
  • Build a wall between performance review and professional development 
  • Use flash mentoring
  • Make the leader occasionally disappear

Establish Purpose

Successful groups use their language and their stories to over communicate why they exist (the difference they make) and how individuals contribute to that difference.

One exercise that uses this principle is mental contrasting; motivation is not a possession but rather the result of a two-part process of channeling your attention.
  • Step 1) Think about a realistic goal that you’d like to achieve.  It could be anything: become skilled at a sport, rededicate yourself to a relationship, lose a few pounds, get a new job.  Spend a few second reflecting on that goal and imagining its come true.  Picture a future where you’ve achieve it.
  • Step 2): Take a few seconds and picture the obstacle between you and that goal as vividly as possible.  Don’t gloss over the negatives, buy try to see them as they truly are.  For example, if you were trying to lose weight, you might picture those moments of weakness when you smell warm cookies, and you decide to eat one (or three)

So aligning motivations can change someone's performance. Similarly replacing one story for another can impact performance.  In one study, when a test randomly identified a child as having "unusual potential for intellectual growth" and those "results" are shared with their teachers; the students test scores and IQ scores increased.

Real-time signals through which team members were connected (or not) with the purposes of the work consists of five basic types:
  • Framing - conceptualize the team mission
  • Roles - why each role was important
  • Rehearsal - teams did elaborate dry runs
  • Explicit encouragement to speak up
  • Active reflection

Other tips Coyle provides to "Establish Purpose" include:
  • Name and rank your priorities
  • Be ten times as clear about your priorities as you think you should be
  • Figure out where your group aims for proficiency and where it aims for creativity
  • Embrace the use of catchphrases:
    • “Create fun and a little weirdness” (Zappos),
    • “Talk less, do more” (IDEO)
    • “Work hard, be nice” (KIPP)
    • “Pound the rock” (San Antonio Spurs)
    • “Leave the jersey in a better place” (New Zealand All-Blacks)
    • “Create raves for guests” (Danny Meyer’s restaurants)
  • Measure what really matters
  • Use artifacts
  • Focus on bar-setting behaviors

Saying from Pixar's Ed Catmull about culture include:
  • Hire people smarter than you
  • Fail early, fail often
  • Listen to everyone’s ideas.
  • Face to everyone’s ideas.
  • Face toward the problems.
  • B-level work is bad for your solution
  • Its more important to invest in good people than in good ideas



1 Comment

Inspired

4/18/2018

0 Comments

 
Picture
​The second edition of Inspired is even better than the first (which I reviewed here and used to be my favorite product management book).

It is the best articulation of how to be successful in product management and how to create successful products that I have ever read. It is impossible not to run into into insights about challenges you are having or have had as a product manager when reading it. (This can be a little creepy, how does he know about all these mistakes I have made, is he a psychic?)  

Do you want to get a job as a product manager? Read and re-read Marty’s book and steal at least a few of his insights for the interview - you’ll sound like a genius.

Some of the topics that resonated for me (I’m sure there will be different ones for you):

-Product management is distinct from other essential roles: design, engineering, product marketing, and project management (Chapter 1).

-Two inconvenient truths that often cause failed product efforts are: at least half our ideas are just not going to work (customers ultimately won’t use it - which is why you need customer validation early in the process) and it takes several iterations to implement an idea so that it delivers the necessary business value (Chapter 6).

-The three overarching product development principles from Lean and Agile which help you create successful products are (Chapter 7)
     -Risks should be tackled up front, rather than at the end.
  -Products should be defined and designed collaboratively, rather than sequentially.
     -Its is all about solving problems, not implementing features.

-You need a team of missionaries, not mercenaries to create the smallest possible product that meets the needs of a specific market of customers (Chapter 8,9).

-A product manager must bring four critical contributions to their team (Chapter 10): 
    Deep knowledge 
        1) of your customer 
        2) of the data 
        3) of your business and its stakeholders 
        4) of your market and industry 

-Product managers (PMs) need product designers - not just to help make your product beautiful - but to discover the right product (Chapter 11).

-Typical product roadmaps are the root cause of most waste and failed efforts in product organizations (Chapter 22).  It is all too easy to institute processes that govern how you produce products that can bring innovation to a grinding halt.  You need to try to wean your organization off of typical product roadmaps by focusing on business outcomes, providing stakeholders visibility so that they know you are working on important items, and by eventually making high-integrity commitments when critical delivery dates are needed (Chapter 60). Part of this is managing stakeholders which includes engaging them early in the product discovery process ideally with high-fidelity prototypes (Chapter 61).

-Products should start with a product vision in which the product team falls in love with the problem, not the solution (Chapter 25).

-Strong product teams work to meet the dual and simultaneous objectives of rapid learning and discovery while building stable and solid releases in delivery.  Product discovery is used to address critical risks: (Chapter 33)
    -Will the customer buy this, or choose to use it? (value risk)
    -Can the user figure out how to use it? (usability risk)
    -Can we build it? (feasibility risk)
    -Does the solution work for our business? (business viability risk)

-PMs can’t rely on customers (or executives or stakeholders) to tell us what to build: customer doesn’t know what’s possible, and with technology products, none of us know what we really want until we actually see it (Chapter 33).

-While Amazon has a culture of “write the press release first”, Marty suggests PM should write a “happy customer letter first."  Imagine a letter sent to the CEO from a very happy and impressed customer which explains why he or she is so happy and grateful for the new product or redesign.  The customer describes how it was changed or improved his or her life.  The letter also includes an imagined congratulatory response from the CEO to the product team explaining how this has helped the business  (Chapter 36).

-Product managers need to consider the role of analytics and qualitative and quantitative value testing techniques (Chapter 54).

-What it really means for a PM to be the CEO of Product is testing business viability: listening to Marketing, Sales, Customer Success, Finance, Legal, BD, Security, etc. before building the product (Chapter 56).

-Establishing a strong product culture requires (Chapters 66-67)
    -Innovation culture: compelling product visions, strong product managers, empowered business and customer savvy teams product teams often in discovery
    -Execution culture: urgency, high-integrity commitments, accountability, collaboration, results orientation, recognition, strong delivery management, frequent release cycles 
    (and it is hard to do both)
    
    

0 Comments

Andrew McAfee and "Enterprise 2.0"

3/7/2010

0 Comments

 
Andrew McAfee coined the term “Enterprise 2.0” and recently wrote a book with the same title. McAfee defines Enterprise 2.0 as the use of emergent social software platforms by organizations in pursuits of their goals.

He begins by saying that many of the problems of the early and largely unpopular computer-supported collaborative work (CSCW) tools (such as groupware and knowledge management applications) were resolved with Web 2.0 technologies that:  

     -are free and easy platforms for communication and interaction (texting, email, IM, etc.)

     -lack of imposed structure on workflow, decision rights, interdependencies, and information.

     -have mechanisms to let structure emerge (search, tagging, etc.)

 
These led to new Emergent Social Software Platforms (ESSPs) such as YouTube and Facebook. ESSPs share technical features such as search, links, authoring, tagging, extensions, and signals (SLATES).

Knowledge workers can take advantage of ESSPs to help them interact with different type of colleagues. For example wikis can help strongly tied colleagues work together more effectively, social networking software can help connect weakly tied colleagues, blogs can help connect colleagues with potential ties (in part by enabling discovery), and prediction markets creates interaction between colleagues who may never form a tie.

The benefits of Enterprise 2.0 come from using features of ESPPs such as group editing, authoring (people publicizing what they know), broadcast search (people publicizing what they don’t know), network formation and maintenance, collective intelligence, and self organization (perhaps the broadest benefit).

The adoption of these new tools can raise concerns around inappropriate behavior and content, the appearance of embarrassing information, and non-compliance with laws, regulations, and policies. However McAfee contends that the benefits outweigh the risks and that most of these risks are actually decreased by Enterprise 2.0.    

It may however be a long haul to adopt these new technologies in part due to our tendency to stay with the status quo even if a better solution exists. Therefore McAfee lays out six organizational strategies for Enterprise 2.0 success which includes:

     -determine desired results, then deploy appropriate ESSPs

     -prepare for the long haul

     -communicate, educate, and evangelize

     -move ESSPs into the flow (of every day work)

     -measure progress, not ROI

     -show that Enterprise 2.0 is valued


Towards the end of the book McAfee says he is most interested in Enterprise 2.0 because it can help organizations move from a Model 1 to a Model 2 style of behavior; from unilateral control of both the goals and the tasks used to accomplished goals to an environment where decision making is based on valid information and where “winning” is replaced with free and informed choices.

“Enterprise 2.0” is a good baseline book on a topic that by its nature needs to be further explored by web 2.0 powered discussions, such as those found on McAfee’s website and blog.

 

0 Comments

My Favorite Book on "Collaboration"

10/17/2009

0 Comments

 
Recently I read a few books on the general topic of collaboration.  The one that was most informative for me was Morten Hansen’s book entitled “Collaboration.”  Published by  Harvard Business Press and written by an INSEAD/Berkeley professor, it is naturally very business focused.  It emphasizes the importance of cultural issues, it suggests several best practices, and it provides many case studies.

Hansen begins by enumerating several collaboration “traps”:
     -collaborating in hostile territory (some organizations aren’t set up to collaborate)
     -overcollaborating (it is refreshing for an author to suggest that his thesis and the title to his book isn’t universally applicable)
     -overshooting the potential value
     -underestimating costs
     -misdiagnosing the problem
     -implementing the wrong solution
  
He suggests that the solution to these traps is “disciplined collaboration … the leadership practice of properly assessing when to collaborate (and when not to) and instilling in people both the willingness and ability to collaborate when required”

The three steps in disciplined collaboration is to:
     1)evaluate opportunities for collaboration
     2)spot barriers to collaborate
     3)tailor collaboration solutions
  
In general, his case for collaboration is that it provides:  
     -better innovation
     -better sales 
     -better operations
which all can lead to sales growth, cost savings, and asset efficiency.
  
The four barriers to successful collaboration are: 
     -not invented here syndrome  (insular culture, status gap, self-reliance, fear of revealing shortcomings)
     -hoarding (competition with colleagues/units, narrow incentives (for own goals), too busy, fear (loss of power))
      -search problems (company size, physical distance, information overload, poverty of networks)
      -transfer issues (tacit knowledge (difficult to transfer), no common frame (don’t know how to work together), weak ties (no strong relations to ease transfer)
  
The three levers to tear down these barriers are:

Lever 1: Unify People - reduce motivational barriers and get buy-in toward a common goal
     One way to do this is to create unifying goals that must
          -create common fate
          -be simple and concrete
          -stir passion
          -put competition on outside
     
     Another is for leaders to emphasize the value of teamwork.  However as they do this, they need to be aware of three “sins” that can happen. 
          sin #1 – small team work kills collaboration. In other words small teams only collaborate among themselves.
          sin #2 – "everyone do teamwork now (except those of us up here)"
          sin #3 – teamwork becomes the point of it all
     
     A language of cooperation also needs to be created.  However, as he has warned earlier, unification or collaboration can be overdone. 

Lever 2: Encourage T-shaped management that rewards both independent results and cross-unit contributions. For example when BP merged with Amoco managers were expected to spend 15%-20% time on cross unit collaboration activities.

     Companies get to this T-shaped management by selection and change:  encourage the belief in T-shaped management, promote and hire those who exhibit this behavior (and selectively fire those who don’t), use pay and bonuses, and provide leadership coaching.

     Collaboration must be measured. SAP has 3 observable degrees of behavior:  “needs development” (misses opportunity to collaborate); “satisfactory” (involves others), “highly effective” (ensures involvement). This data must be must be collected, measured, and have consequences. Employees need to be coached on this behavior, they must be given a way to do it. Performance pay needs to be based on a mixture of individual, business unity, and corporate performance.

Lever 3: Create nimble, not bloated networks across organizations that deliver results
     1)build outward (not inward)
     2) build diversity, not size
     3) build weak ties, not strong ones
     4) use bridges, not familiar faces
     5) swarm the target, don’t go it alone
     6) switch to strong ties, don’t rely on weak ones

Finally the author discusses how you grow to be a collaborative leader
     -put personal goals and interests second
     -involve others (from autocractic to inclusive)
     -be open to people, alternatives, and debate 
     -be accountable

 
0 Comments

"The Culture of Collaboration"

10/17/2009

0 Comments

 
While "Collaboration" by Hansen is my current favorite collaboration book, “The Cultural of Collaboration” by Evan Rosen provides several important insights.

Rosen says that an increased demand for collaboration is being fueled by technology, economic, cultural, and regulatory trends.  He also says that the elements that are typically present when collaboration work include: 
     -a culture that values, trust, sharing, communication, and innovation
     -an organization with common goals
     -a well-design physical and virtual environment
     -the existence of some collaborative chaos
     -the room for constructive confrontation
     -a sense of community
     -an ability to create value with collaboration
 
When discussing the advantages of a culture of collaboration, Rosen states that “Internal competition delivers results short term, but collaboration builds long term value.”  A collaborative culture increases the likelihood of spontaneous interactions which are valuable for an organization.  It also increases knowledge sharing and mentoring.

Overall, the common attributes of a collaborative culture includes:
     -frequent, cross-functional interaction
     -leadership and power spread around an organization
     -people being accessible regardless of their level
     -reduced fear of failure
     -broad input into decisions
     -cross-pollination of people
     -spontaneous or unscheduled interaction

     -less structured interaction
     -formal or informal mentoring
     -tools that fit work styles

A culture of collaboration enables lifestyles and workstyles such as mobile and deskless workers.  It also enables three modes of work: process, project, and incident and breaks down organizational silos.   

However beware of how collaboration is promoted in a company. "Too often organizations introduce collaboration approaches, processes, and tools without linking them to organizational principles. This confuses users and stalls integration into work styles.”  As demonstrated by Toyota:  culture + process + tools = collaboration

Rosen provides a good list of communication and collaboration tools and discusses how to choose the right tools for the right situation.  He also discusses how compliance drives and complicates collaboration.

A company can create a culture of collaboration by
     -establishing a mentoring system
     -inviting constructive confrontation
     -integrating collaborative tools into work styles
     -facilitating cross-functional brainstorming
     -rewarding people for gaining broad input
     -rewarding people for sharing information
     -incentivizing people to innovate
     -promoting collaborators
     -practicing collaborative leadership
     -using collaborative voice tone
     -avoiding internal competition trap
     -creating open physical environments and virtual environments
   
A good example of a global collaborative enterprise example is Boeing which went from linear to concurrent design by using:
     -low-level collaboration  (text discussions, some video/web conferencing synchronous)
     -mid-level collaboration with partner companies via a web-enabled consortium
      -high-level collaboration or design work between global partners (designing parts, plans, tools)
  
In general, a global collaborative enterprise:
     -recruits the best talent regardless of location
     -develops products and services in real time
     -leverages mirror zones (teams in opposite time zones)
     -exploits global work and job sharing
     -capitalizes on input from multiple regional cultures
     -capitalizes on input from multiple organizational cultures
     -recognizes interdependency among business partners
     -provides dedicated collaborative spaces
     -integrates collaborative tools and capabilities into work styles
     -uses visualization tools when doing design

 
0 Comments

Innovation Games

5/1/2009

0 Comments

 

It isn't the job of your customer to translate their needs into your product offerings. Of course, everyone says you just need to listen to your customer, but no one says how.  In "Innovation Games" Luke Hohmann describes 12 games you can play to help you better understand your customers' needs and help you discover great products.

In part I, Luke first provides an overview for understanding and implementing innovation games.  He then discusses the process from selecting the game to interpreting the results.  

In part 2, twelve separate games are described which can help you understand one or more of the following:
    - Unmet and/or idealized market needs
    - Products and services usage and relationships
    - Product and service functionality
    - How to shape your product for the future

Finally, in part 3 tools and templates are provided to help you quickly start playing innovation games with your customers.

In a world where the mantras of "innovate" and "listen to your customer" prevail, Luke Hohmann gives you usable tools to help you do just that.

(Besides this book, also check out the innovation game entry in Wikipedia and the www.innovationgames.com, although at this moment the site seems to be down.)

0 Comments

Concise but Detail Rich Book Which Covers a Few Key Areas of Product Management / Product Marketing

12/20/2008

0 Comments

 

Expert Product Management: Advanced Techniques, Tips & Strategies for      Product Management & Product Marketing  
By Brian Lawley

This is a good tactical book which focuses on a few key areas of product management and product marketing:  product roadmaps, beta programs, product launches, and review programs.  If you need to perform one of these important functions, then read this concise but detail rich book and follow-up by checking out all the additional resources on the author’s (www.280group.com) website.

Lawley first discusses roadmaps including the different types (market & strategy, technology, platform, visionary/trends, etc.) and the eight step process for building a roadmap. He then details the logistics behind running a successful beta program and then a successful product launch. Finally he talks about how to get (hopefully favorable) reviews for your new product.

“Expert Product Management” is a detailed primer for these essential product management / product marketing activities.  Lawley also presents topics I haven’t seen in similar books such as using a variety of roadmap formats and how to create a buzz about your product with product reviews.

0 Comments

Autonomy, Complexity, and a Connection between Effort and Reward

11/26/2008

0 Comments

 

"Three things – autonomy, complexity, and a connection between effort and reward – are, most people agree, the three qualities that work has to have if it is to be satisfying.  It is now how much money we make that ultimately makes us happy between nine and five.  It is whether our work fulfills us."

"Work that fulfills those three criteria is meaningful.  Being a teacher is meaningful. Being a physician is meaningful. So is being an entrepreneur…"

-Malcolm Gladwell “Outliers: The Story of Success”

As mentioned in the New York Times article "It May Be a Good Job, but Is It 'Good Work'?" (11/16/08), the Harvard Psychologist Howard Gardner says:

"There are three questions people can ask about their jobs to evaluate their good-work level: Does it fit your values? Does it evoke excellence; are you highly competent and effective at what you do? Does it bring you that subjective barometer of engagement, joy?"MR. GARDNER’S advice for anyone being forced to find a new job, setting out on a career or hankering for a midcareer change is: “Decide what you really like to do and what you would like to spend your life doing. That’s more important than deciding what particular job to hold, because the employment landscape is changing radically and quickly. Then ask, ‘Where could I carry that out?’ and be very flexible about the milieu and venue — but not about what you get a kick out of and can be good at.“And then, third, if you have any choice over where to work, when you’re considering a job, go there and talk to people. Ask yourself, ‘Is this the kind of place where I can see myself in others?’ You might make five times more money at one place, but does it reflect who you are and who you want to be? Are my colleagues people I’d admire or people I’d prefer to avoid?”

0 Comments

Product Manager? Building Software Products? Read Marty Cagan's Book Inspired

11/8/2008

0 Comments

 

I have always been interested in how great software products are built. In the early 90’s, I took several  “software engineering best practices” courses at Boston University as part of my doctoral studies. Since then I have read many books and articles and have lead many software product development and product management teams. Now I even teach a course at Stanford on product management and the software product lifecycle. 

Marty’s Cagan’s book is by far the best book I have ever read on software product management, or really on how to build great products.

His general theme of discovering products that are “valuable, usable, and feasible” is brilliant. He discusses the role of the product management including contrasting it to product marketing, project management, design, and engineering.  He lays out a guideline for product management processes including how to succeed with agile methods, waterfall processes, in a start-up, and in large companies.  It is hard to believe he covers so many useful topics (cutting features vs. slipping dates, market research, innovating in large companies) and classic problems (confusing product management with product marketing) in this relatively short, very straightforward, and very readable book.

If you are a product manager or just want to learn how to build great software products, but this book!  Then buy one for everyone on your team, for everyone around you, and especially for your CEO. (Oh, you are the CEO; then what are you waiting for?)

0 Comments
<<Previous

    Categories

    All
    Books
    Careers
    Cloud Computing
    Culture
    Energy
    Enterprise2
    Humor
    Marketing
    Product Management
    SaaS
    Smart Grid
    Strategy

    Archives

    July 2022
    March 2022
    January 2022
    July 2021
    June 2020
    May 2019
    April 2019
    November 2018
    April 2018
    February 2018
    September 2017
    July 2016
    August 2014
    March 2014
    November 2013
    October 2013
    September 2013
    July 2013
    May 2013
    June 2012
    March 2012
    March 2010
    October 2009
    September 2009
    August 2009
    June 2009
    May 2009
    March 2009
    February 2009
    January 2009
    December 2008
    November 2008
    October 2008

    RSS Feed



    The postings on this site are my own and don’t necessarily represent my company's positions, strategies, or opinions