# Strategy

s we enter a new year, with core documents complete, the Xalgorithms foundation enters a new stage in the development life cycle. Guided by a set of documents authored by Bill and Joseph, this phase was marked by a set of assumptions that were articulated to intentionally guide the planning, requirement and design phases. The following timeline shows where in the process we are.

Planning | Requirements | Design | Implementation | Testing | Post  Release 

-- | -- | -- | -- | -- | --

 | | | x | 

On the most recent tech call a number of important topics of conversation came up. 1. the nature of the rule taker interface. 2. the reason for developer adoption of DWDS. 3. the capabilities of rule maker. 4. the effective allocation of resources across this project. 

Many answers were hinted at. However, significant ambiguity remains. As we approach the task of defining the work of the next quarter, it is imperative to reflect upon the nature of the design that is being implemented, to make explicit the assumptions we hold, and to determine how our strategies can best support the system that has emerged from the previous stages in the project life cycle. 

This process will inform and improve our ability to define work across the implementation of DWDS and the accompanying communications and project management strategy. It will make it easier to make effective use of limited resources, and make it easier to make decisive decisions.  

This process will require asking a series of pointed questions and using various narrative and cognitive techniques to help approach answers.

First. It is important to examine assumptions about how DWDS is used. In essence, what kind of person is going to the primary person using this technology. This question has been touched upon before, without satisfaction. The assumption being that it is next to impossible to define a target user in the context of general purpose technology. However this assumption is false. Look at the narrative maps and you will see a common thread. 

[narrative maps](https://www.figma.com/file/wecDOah0hvb4G1rtreJifa/DWDS-in-Use?node-id=0%3A1)

Every story requires developer integration of DWDS. The developer is the common character across all the different applications proposed. This does not mean the users of client applications are irrelevant. In fact it is just the opposite. The needs of the end user is of the upmost importance to the developer. That is why the many considerations made during the design phase regarding human centered use and ease of utility (of both RM and RT) is a major reason for developer adoption. However, as Ted clearly stated, DWDS will never benefit any end users if developers cannot over come the costs associate with employing this novel technology.

To better understand these costs, it is helpful to put them into human terms. The following persona is used to help clarify these questions. 

[persona](https://www.figma.com/file/FyJu1ghz8Den96mr5W6Bfv/Persona?node-id=0%3A1)

A persona is an important tool. It plays a role making biases explicit. It also provides a tangible document that can build alignment and guide strategic decision making. 

So let's consider these questions that have emerged in the past week with the persona of Emma in mind:

1. What is the purpose of building out RT? What goals must a prototypical interface meet?

2. What is the best way to allocate limited resources across DWDS development? How does this inform decisions about work being done on RM?

3. How does this inform the ongoing conversation about communications, project management, and distributed organization? 

4. How are these transformed into concrete objectives that can synthesized into high level tasks?