When we hired a new CTO at Valore, we rolled out agile/scrum with our product and engineering teams. We had been in the waterfall dark ages. We predictably experienced every bad outcomes one could expect from a misaligned development process. It took some time for the team to understand it, get comfortable with it, and realize the many benefits of it.
A sampling of the many benefits we have experienced from adopting scrum include: Continue reading “Implementing scrum for non-software teams”
Why don’t business people practice?
Sports and business are always compared. There are an endless number of analogies used every day – teams, winning and losing, star players, competitors, etc. The comparison holds, for the most part. Except for practice. Why?
Athletes at all levels know that they will need to practice their ass off to compete at the highest level. Daily images of athletes toiling away in the anonymity of the empty practice field or gym stream over the airwaves to us. Continue reading “Practice”
Speed wins. Startup dogma. Silicon Valley platitude. Dangerous concept that is often misinterpreted.
People hear this and think of the mythological developer who just cranks things out at lightning speed. Working all night, crushing Red Bulls, typing furiously on their laptop. There are many flaws with that mythology that I won’t go into here, but why does that mythology exist in the first place? Business executives are the reason. Continue reading “Speed Wins”
The “Line of Chaos” is a concept that good product managers will not just understand, but will embrace with vigor.
First, let’s start with what it is. It is an imaginary line that serves to illustrate the interface between business and technology. Why does that interface matter? It matters because business people and engineers are fundamentally different.
Recall the post by Paul Graham about Makers vs. Managers. Business people, especially sales people, thrive on selling, meetings, making clients happy, reacting to the client or market, the (not so) occasional fire-drill, and often just raw activity. They are interrupt-driven. How many times have you heard someone say, “I’m so busy! Look at all the meetings I have on my calendar.” They frequently switch context. They lie in the now. It is often fluid, reactive, and, well, chaotic.
Engineers (I’d include designers in this too) thrive on long blocks of deep thinking to solve problems. Output should be the measure of productivity for engineers, not the activity or the lines of code. In fact, time to think, not code, may result in the best output (a scalable design or elegant feature, for instance).
None of this is controversial. The thing that isn’t mentioned in the PG article is how those two different worlds can work together to great effect. This is where product managers step in. They are responsible for defending the engineers from the chaos. In some ways, they are responsible for saving the business people from their own chaos (even if they might not know it at the time). PMs are the keepers of the Line. Good PMs will fight to the death to ensure that the Line does not penetrate the engineering team.
The keeping of the Line of Chaos takes many forms for a PM. Prioritization. Stakeholder management. Feature benefit analysis. MVPs. Product strategy. At the end of the day, these and other common principles of product management are just tools to fight back the Line of Chaos.
This is not to say that the Chaos does not serve a purpose. It does. Great ideas often emerge from the chaos. But, even then, the idea is going to need some help to get presented to the engineers in a way that puts them in a position to be successful.
Great product managers are hard to find. There aren’t a lot of people who can both operate in the chaos, while simultaneously fighting it.
It is very complicated.
It can be anything. It can be a program, a script, a process, an integration or any other situation, problem or context you may confront in your day.
Do not let someone trick you. Do not confuse complicated with complex. Things can be complex without being complicated. When people try to complicate things, they are masking their root motivations.
Complicate – make something more difficult or confusing by causing it to be more complex
Complex – consisting of many different and connected parts
As a product manager, if you hear these words, or some variation of them, alarm bells should go off and you should proceed with caution. Complexity is a weasel word that, in my experience, is too often used to put up blockers, protect one’s “turf,” or undermine collaboration.
At the most basic level, when you hear this, the person who is telling you all about how complex the issue is, is really just trying to prevent you from understanding what’s going on. There can be many reasons for not wanting you to understand what’s going on, but none of them are ultimately acceptable. The inability to understand is crippling to a PM. After hearing this, and since you’re the ultimate, truth-seeking PM, you need to roll up your sleeves and get to the bottom of the situation. The reality is that it’s going to be messy, but probably not for the reasons you are being told that “it’s complicated.”
newmanea 