|
|
Blog Articles
Viewing entries tagged with 'product development process'
Engineers and Sales People
Believe it or not, there are still people out there that think that a technology company is really about two types of people: engineers and sales people. People to write the software, and people to go sell it. Everyone else is overhead and at best a necessary evil.
Top 10 Reasons for Weak Product
In my last article I discussed the top reasons for slow product, and here I wanted to highlight the top reasons for weak product. I am defining weak product here as product that fails to meet its objectives and provide new and expanded sources of revenue and/or growth for your company.
Technology First vs. Needs First
There’s a debate that’s been going on in the design and user research community because the legendary Don Norman wrote an essay in which he did an about-face and decided that doing user research to start a project was mostly a waste of time.
No Silver Bullet
More than 20 years ago Fred Brooks published a seminal essay on the nature of software, called “No Silver Bullet: Essence and Accidents of Software Engineering”. If you’ve never read it I’d highly encourage it, as even though it’s ancient by the standards of our industry, it’s still amazingly relevant and gets to the heart of why creating great software is so hard.
How To Kill Innovation
Last week I ran into two different software technology companies (neither in Silicon Valley) that had just recently brought in Six Sigma consultants. This caught me by surprise because it¹s been a very long time since I heard of a technology company even considering this. I'm hoping this was an anomaly, but in the spirit of "those who cannot remember the past are condemned to repeat it," I thought it's important to discuss quality-centric methodologies like Six Sigma.
Product Discovery Diary
When product managers and designers move from the very linear, Waterfall-based processes, to the much more iterative and exploratory discovery-based process that I and others advocate, they sometimes take a little while to appreciate and adapt to the fast pace and rhythm of product discovery.
Left Of The Line
I picked up this phrase “left of the line” from my friends at the e-commerce site kbb.com. At the highest level, creating software products involves figuring out what to build, and then building it. This line distinguishes those two fundamental activities. Note that this line exists whether you use conventional product development processes or an Agile/Scrum process, although the nature of the line is different.
The Origins of Agile
If your engineering team hasn’t already moved to some form of Agile methods (like Scrum or XP), then it’s likely they’re at least considering it. Agile really does attack some key problems that have plagued software teams for decades. But many product managers and designers, and to a lesser extent QA staff, are initially confused by Agile, unsure of their role in these methods. To be clear, these methods absolutely require these roles, but I attribute the confusion to the origin of Agile methods, and I’ve found that when I explain the origins, it helps to illuminate the problems that Agile was designed to solve, and what challenges remain.
The Product Council
Even in small companies, getting decisions made is often time-consuming and frustrating. Every product company needs a mechanism to get the key stakeholders and decision makers together to make timely and informed product decisions.