E022 Product Strategy carries the banner number ITIM 6600 and is worth 3 competency units. It is the planning half of a technical product manager's job: strategizing the needs, the requirements, the costs and the metrics that decide whether a design succeeds, with user research and product planning as the working methods. E022 and ITIM 6600 are one requirement. It is the first course in a three step sequence that continues into design and then launch, and the discipline it drills is refusing to build before you have evidence of a need.
A need is discovered, not assumed
The failure mode this course is built against is the product that solves a problem nobody has. Almost every student draft starts from a solution the writer already likes and works backward to a justification for it. E022 wants the opposite order: evidence of a need, a definition of who has it, then requirements that follow from the need, then a cost and a set of metrics that would tell you whether you were right.
User research is the mechanism, and the course treats method as part of the answer. Who you asked, how you asked, how many, and what you did with contradictory responses all belong in the submission. Research that consists of the writer imagining what users would say is the single easiest thing for an evaluator to spot, because invented research is always tidy and real research never is.
Requirements are where the discipline shows. A requirement states what the product must do, in terms that can be verified, without prescribing how it is built. Statements that hide a design decision inside a requirement close off options before anyone has evaluated them, and statements too vague to test cannot be used to accept or reject the finished thing. Separating functional requirements from constraints and from aspirations is most of the work.
Metrics get chosen at strategy time on purpose. Picking success measures before building forces honesty, because you are committing to a number while you still might be wrong. Picking them afterward guarantees you will choose whichever number the product happened to move.
WGU marks work Competent or Not Competent instead of issuing letter grades, keeps no ordinary grade point average, and sizes this course at 3 competency units inside a flat rate six month term.
Turning scored aspects into a strategy document plan
If your version of E022 uses a performance assessment, the aspects your evaluator scores are the specification for the document. WGU requires a score of 2 in each aspect for a task to pass and scores each aspect separately, so depth in the research section will not compensate for a metric aspect answered in one line.
Budget in advance. Imagine a rubric holding six scored aspects and a target near 2,100 words. Reserve 160 words to name the product concept and the market it addresses, and 140 for the close, leaving 1,800 words to allocate. Three aspects that demand evidence and derivation, typically the need, the requirements and the cost, take 380 words each, which is 1,140, because each needs the input, the reasoning and the output stated separately. The three remaining aspects, usually covering audience, competitive position and metrics, take 220 each for 660. Together they come to 1,800 exactly.
Write the aspects in dependency order rather than rubric order if the rubric allows it, then map back. Need comes before requirements, requirements come before cost, and cost comes before whether the metric target is achievable. A document written in that order argues; a document written in checklist order lists.
Keep one paragraph of budget for what you decided not to build. Scope exclusions are a strategy output, not an omission, and naming them is one of the clearest signals that a real decision was made.
Shape for a product strategy document
E022 deliverables usually argue that a specific product should exist. These proportions carry that argument.
| Section | What belongs there | Share |
|---|---|---|
| Product concept | What it is, in two sentences, written so a reader outside the team understands it. | 7 percent |
| Users and need | Who has the problem, what evidence says so, and how they cope today. | 20 percent |
| Research method | How the evidence was gathered, from whom, and what its limits are. | 13 percent |
| Requirements | Functional requirements, constraints and exclusions kept in separate lists. | 20 percent |
| Cost and resourcing | What building and running it takes, with the assumptions visible. | 15 percent |
| Success metrics | The measures, their targets, their time frame and what would count as failure. | 17 percent |
| Close | The biggest assumption in the plan and how it gets tested first. | 8 percent |
Evidence for product claims
Product work has an evidence problem students underestimate: the most important claims are about people, and claims about people need either primary research or a cited secondary source. Saying that users find a task frustrating is a research finding if you asked them and an opinion if you did not, and the difference has to be visible in the writing.
Where your course allows small scale primary research, report it honestly, including the sample size. Six interviews is a small sample and saying so costs you nothing, while implying a survey of hundreds costs you the aspect if the method section does not support it. Report the responses that did not fit your hypothesis too, because their absence is what makes fabricated research look fabricated.
For market and competitor claims, use sources a reader can reach: published market research, company documentation, regulatory filings, professional bodies. Reachable and dated beats impressive and vague. Where a competitor claim comes from using the product yourself, say that, since a firsthand observation identified as one is legitimate evidence.
Cost claims need the same treatment they get in any financial argument: inputs visible, assumptions declared, one calculation shown in full. Use the citation style the task specifies, cite where the claim appears, and make sure every reference in the list is used somewhere in the text.
What earns Competent, and what comes back
Competent strategy documents can be traced backward. Every requirement points to a need, every need points to evidence, every metric points to a requirement, and the cost figures point to inputs. They also make a decision visible: this product, for these users, not that one, and here is what we are choosing not to do.
Returns follow a small number of patterns. Research appears as assertion with no method behind it. Requirements are written as solutions, so the design is already fixed before the design course. Metrics are activity counts that would rise whether or not the product worked. The cost section is a single number. Or the document describes an idea enthusiastically and never states what problem it removes.
One check that catches most of it: draw a line from each success metric back to a requirement, and from that requirement back to a piece of evidence. Any metric that cannot make the trip is measuring something the strategy never claimed to deliver, and any requirement with no evidence behind it is a preference.
Revision and resubmission of performance assessment work carry no grade penalty at WGU, so release the draft once every aspect has a genuine answer instead of holding it for polish. If your section of the course also carries an objective assessment, that exam is proctored and our position is fixed: we prepare you in advance with concept work, practice questions and a candid read of your preassessment, we stay out of the assessment itself entirely, take no role while it is running, and never request or hold portal credentials.
Solution first, evidence later?
Send the E022 rubric and your product concept. We rebuild it need first, with requirements that trace to evidence and metrics that trace to requirements.
Six mistakes that cost time in E022
- Starting from the solution. If the product existed before the research, the research will read as decoration. Build the need first, even in the draft order.
- Research with no method. Say who you asked, how many, how, and what did not fit. Findings without a method are opinions with confidence.
- Requirements that specify implementation. State what must be true, not how to build it. The how belongs to the design course that follows.
- Vanity metrics. Sign ups and page views move for reasons unrelated to whether the need was met. Pick measures that would fall if the product failed.
- No exclusions. A strategy that says yes to everything has not made a decision. Name what is out of scope and why.
- A single cost number. Build, run and change all cost differently. One figure hides the one that will actually be argued about.
Three questions students ask about E022
Can I use a product idea from my own workplace?
How much user research is enough?
Is E022 the same course as ITIM 6600?
Where E022 sits in WGU's programs
The July 2026 catalog places this code in 1 current WGU program. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.