Forbes quoted Steve Jobs as saying “I’m as proud of what we don’t do as I am of what we do.” This is a really enlightened perspective – and a way to enforce focus from the top down. Before you can drive a “this goal is more important than that […]
Good Enough
We hear a lot about building products which are “good enough” or “just barely good enough.” How do we know what “good enough” means for our customers? No one really tells us.
Why Write Requirements
There is a lot of advice out there for how to write requirements. There is not as much discussion about why to write requirements. Spend some time thinking about why you write requirements before you make decisions about how to write your requirements.
Cargo Cult Requirements
Is your team focusing on the mechanics of creating good software, without understanding the connections from your efforts to your goals? Are you primarily focused on the structure of use cases, the syntax of user stories, and the cardinality of your domain diagrams? All of these things are important to […]
Business Goals and Requirements
One of my colleagues got into a debate with one of his colleagues about the differences between goals and requirements. His opponent fired the following salvo: “[That] is not a business requirement in any company of the world…” What you call your requirements is less important than how you communicate […]
How Do You Manage Market Data?
Great product management starts with an insightful understanding of your market. Not just understanding a customer, and not even understanding all of your customers, but understanding your target market. What works for you?
Problems Are Everywhere
Today’s article is a harvest of pointers to articles about the focus on problems. An idea farm, so to speak, with really good articles about the importance of solving problems, not just eliciting requirements.
Flashback: This Week in the Past on Tyner Blain [May 3]
A look back at the best from this week in the past.
Business Architecture, Rules, and Requirements
We know to treat business rules and business requirements differently. One example – treat external government regulations as rules (because they are less subject to change than requirements). When you have multiple systems in an architecture, while “rules” makes sense for one system, “requirements” make sense for another. What do […]