Respecting the Power of Good Product Management with Rich Mironov on Hack the Process Podcast, Episode 23

Quick, explain the differences among Sales, Marketing, Engineering, and Product Management. If you work in a company with one or more of these organizations and the answer doesn’t trip easily off your tongue, then you might want to listen to Rich Mironov. Rich is a Product Management expert who helps companies understand and respect the differences, and improve how these groups work together. Rich makes the case that “Product is not in charge of shipping on time, but Product is in charge of shipping the right thing that customers need and will pay for.” In this episode, Rich discusses exactly how he builds and maintains his strong social network, explains how leading workshops helps him stay on top of his industry, and points out the importance of defining a problem/solution set that will allow you to sell a benefit that addresses a problem your customers actually have.

Where to find Rich online

Website and blog: http://www.mironov.com/

Books: http://www.mironov.com/book/

LinkedIn Articles: https://www.linkedin.com/today/author/richmironov

LinkedIn Profile: https://www.linkedin.com/in/richmironov

Twitter: https://twitter.com/richmironov

Resources Rich mentioned

Evernote: https://evernote.com/

Tristan Kromer: http://www.tristankromer.com/

Laura Klein: http://www.usersknow.com/

Hewlett-Packard: http://www.hp.com/

IDEO: https://www.ideo.com/

Rolodex: http://rolodex.com/

Myers-Briggs Test: http://www.myersbriggs.org/my-mbti-personality-type/mbti-basics/

LinkedIn: https://www.linkedin.com/

VMWare: http://www.vmware.com/ap

Salesforce: https://www.salesforce.com/

Dropbox: https://www.dropbox.com/

Teresa Torres: http://www.producttalk.org/about/

Agile Management for the Unmanageable with Ron Lichty on Hack the Process Podcast, Episode 9

In this episode we chat with Ron Lichty, who discovered his passion for technology early on, when he realized that programming in assembly language was easier for him than writing in English. And he knows the difference, because he’s also worked as a journalist and published several books with co-authors. His most recent book, Managing the Unmanageable, is about how effective management can help software engineers achieve the ecstatic state of flow that Ron says coding in a productive environment can produce. We ask Ron about how he gravitated toward management despite his enthusiasm for programming, how and why he took his career from full-time employee to independent consultant, and what his experiences writing with co-authors have taught him about collaboration.

Where to find Ron online:

Ron’s website: www.RonLichty.com

Managing the Unmanageable: http://www.managingtheunmanageable.net/

Managing Software People and Teams LiveLessons: https://www.safaribooksonline.com/library/view/managing-software-people/9780134507071/

Ron’s LinkedIn Profile: http://www.linkedin.com/in/ronlichty

Resources Ron mentioned:

Agile Software Development: http://www.agilemanifesto.org/

Scrum: https://www.scrum.org/

Kent Beck: https://en.wikipedia.org/wiki/Kent_Beck

Starting a New Book on Scrum

I was really excited when my publisher, SitePoint, contacted me and asked me to write a book about scrum for mobile and web development teams. I’ve been writing articles about web development and scrum for SitePoint for a little over a year now. And when I did the math, it turned out I have over 10,000 hours of experience leading and participating in scrum engineering teams doing web or mobile development.

What really impressed me was the way the process was structured to make sure the book got written and edited efficiently. SitePoint uses Github to track changes and manage feedback. The entire manuscript is written in markdown and submitted through pull requests for each chapter. Editors for content, copy, and overall project management are assigned at the start, and an agreed schedule breaks down the writing time separately from the revision time.

Writing long-form pieces is always challenging, but a structure like this seems more likely to result in a finished piece and a predictable timeline. Every chunk is clearly defined before starting, and seems do-able.

Wish me luck!