Corporate Goals for the Product
We have two corporate goals for our agile project. One of them directly drives the features and functionality, and the other one is a driver of a constraint on the implementation approach. Both types of goal are relevant.
A process that relies on structured requirements always starts with goal definition. Even if we are combining principals of interaction design with structured requirements, we still need to understand our corporate goals. It is from this understanding of goals that we can move forward to developing a contextually relevant understanding of our users.
1. Make it easier for people to find and read great content in our niche.
This is the primary corporate goal for Tyner Blain in creating this site / product. We’re taking an ideation step in deciding that the particular approach (promoting and sharing articles as a community) will be the one we take to address our goal.
The question is – How do we get from an MRD to a great PRD?
A product requirements document (PRD) captures the capabilities of the software in order to address the market needs. From these key capabilities comes the design of the software. How do we get from needs to ideas?
This is an ideation task. A product manager must apply high level design skills when writing the specification. Haven’t we said repeatedly that requirements should not describe the implementation or design? Yes. Previously, we talked about the importance of asking why, this is the same issue, approached in the other direction – starting with the why and asking how.
2. Deploy a simple project using Ruby on Rails as an evaluation of the technology.
While otherwise irrelevant to the project, this is a driving goal for our decision to do the project. We have an internal need to evaluate the technology for other projects. For our evaluation of rails we need to understand the following:
- Ease of deployment – both initially and of updates.
- Speed of development – is it really as fast as people say? Will customization of scaffolding eliminate this benefit?
- Scalability – the FUD on the street says there are issues with database load balancing.
- Testability – how easy is it to develop with a continuous integration process?
- REST / SOA Capabilities – how easy is it to create a REST-service provider for use in an SOA deployment?
- Architectural Nuance – we’re biased towards separation of UI from business and application logic. Does the MVC convention in rails achieve the benefits it promotes, and do we like using it the way it is intended.
