Role Responsibilities and Success Criteria Questions

Direct answer

"Product portfolio scope" is the set of products or product lines you own as a technical authority across all your accounts (defined by your manager or practice lead, and fairly stable across quarters). "Engagement scope" is what a single customer deal or project actually commits you to deliver (defined per deal in a Statement of Work, or SOW, and changes constantly). A Solutions Architect (SA) who conflates the two either overcommits inside one deal or under-serves customers on products they thought were out of bounds.

Three ways they diverge

1. A request falls inside your portfolio but outside this engagement: a customer whose engagement is scoped to "migration only" asks you about a security posture review that's in your product portfolio but never appeared in the SOW. You can give an informal, time-boxed take, but the real work needs a scope change.
2. A request falls inside this engagement but outside your portfolio: the customer expects you (the assigned SA) to advise on a product line you don't personally own, because from their side "the SA" covers everything in the deal. Here you pull in a specialist rather than improvising.
3. The engagement clock ends before the portfolio relationship does: a 90-day onboarding engagement finishes, but you remain the portfolio owner for that account's product line indefinitely, so renewal and roadmap conversations continue long after the SOW closes.

How this changes success metrics and priorities

If you're measured at the engagement level (time-to-value for this SOW, this account's satisfaction score), you optimize for finishing this deal's committed deliverables, even if that means declining upsell conversations. If you're measured at the portfolio level (adoption of a product line across many accounts, revenue influenced company-wide), you prioritize work that never maps to a single SOW: competitive positioning, product feedback, reusing patterns across accounts. A strong SA tracks both and is explicit with the customer and their own manager about which lens a given request falls under before agreeing to it.

Trade-offs and pitfalls

Treating everything outside the literal SOW as "not my job" frustrates customers and leaves expansion revenue on the table. Treating every portfolio-adjacent request as automatically in scope blows engagement timelines and stretches you across products you don't actually own well. The failure mode to watch for is doing unbilled, unscoped work that never shows up in either your engagement or portfolio metrics.

Direct answer

I'll write this for a Solutions Architect (SA) joining a customer-facing technical practice, because that is the role where the ambiguity is worst: your remit spans several products and several open deals at once, and nobody hands you the boundary between them. Build the first 30 days around three unknowns, not a generic ramp plan: what is my scope, who do I report to and work alongside, and how will my success actually be measured. Every week should produce one concrete artifact that proves you've resolved part of that ambiguity, not just that you had conversations.

Stakeholders to meet, and the objective for each meeting

• Your manager or practice lead (a senior SA who leads a practice area, a group of SAs organized around one product line or vertical, and who may shape your scope even when they aren't your direct manager): confirm product portfolio scope, reporting line, and review cadence.
• The sales or account leads you'll partner with: understand how engagement scope gets defined per deal and how your time gets allocated across them.
• A senior peer Solutions Architect: learn the unwritten norms about scope boundaries and when to escalate.
• A Product or Engineering counterpart: find where your technical authority ends and theirs begins.
• A Customer Success or Support lead: understand the handoff point where your engagement scope ends and theirs begins.

Documents and dashboards to request

Your role charter or job description, the org chart, this quarter's Objectives and Key Results (OKRs, the goal-and-metric framework the team plans against) for your practice, a sample Statement of Work (SOW, the document that defines what one customer engagement commits you to), and any historical dashboard tracking SA performance metrics like win-rate influence or customer satisfaction.

Systems to get access to

The CRM (customer relationship management system, e.g. Salesforce) for deal visibility, the deal-desk or SOW repository, the support ticketing tool for post-sale handoffs, and whatever dashboard tracks the KPIs (key performance indicators, the specific numbers you'll be judged on) you'll be measured against.

First three deliverables to demonstrate early impact

1. A one-page "my scope" document, drafted after week-one conversations and circulated for correction, stating your product portfolio and typical engagement boundaries. This forces any misalignment to surface early instead of months later.
2. A completed technical deliverable on one live, low-risk engagement within the first two to three weeks, to establish credibility while the scope document is still being validated.
3. A draft "success metrics" one-pager reviewed with your manager by day 30, so ambiguity about what "good" looks like is resolved before your first real performance conversation.

Trade-offs and pitfalls

Don't wait for the 30-day mark to raise a scope conflict once it's visible, escalate it as soon as it appears even if your documentation isn't finished. The main pitfall is treating this like generic onboarding, learning tools and process, instead of deliberately driving toward scope and metric clarity, which is what actually distinguishes a strong first month from a merely busy one.

In short: A proposal or Statement of Work (SOW, the contract listing scope, deliverables, and price) should never promise an outcome without also stating, in the same document, exactly how and when that outcome gets checked.

Three example clauses

Worked example: take the adoption milestone clause and run it to the day-60 check. The customer's 'target user group' is pinned at signature to a named list of 400 users, so the 80% target is 400 x 0.80 = 320 users onboarded by day 60. At the check-in, onboarding-completion telemetry shows 268 completions, which is 268 / 400 = 67%, well short of the 320 the clause requires. Because the clause named its source of truth (the product's own login and onboarding-completion telemetry) and its denominator (that list of 400 named users) before signature, the day-60 meeting is spent on why, not on whose number is correct, which is the whole point of naming both in advance.

That same example exposes the adoption clause's real weakness, which the performance and acceptance-test clauses do not share. Investigating the miss shows 90 of the 400 named users had never been granted licences by the customer's own IT team, so they could not have onboarded at all. Measured against the 310 users the customer actually provisioned, 268 completions is 86%, which clears the 80% bar. The vendor missed a contractual target on a dependency the vendor does not control.

The controllability problem with adoption clauses: performance and acceptance-test clauses measure something the delivering team fully controls, so tying them to a payment gate is clean. An adoption clause does not: onboarding completion depends on the customer provisioning accounts, freeing users' time, and doing its own internal change management. Tying an uncontrolled measure to a payment milestone is the most common reason these clauses get renegotiated mid-engagement or quietly ignored. The fix is not to drop the clause, since adoption is the outcome both sides actually want, but to write the customer's dependency into the clause itself, for example 'measured against users provisioned by the customer within 14 days of go-live, with a joint adoption-plan review rather than a payment consequence if provisioning falls below 90% of the named list'. State the remedy asymmetry deliberately: full payment consequence for the clauses you control, escalation and a joint plan for the ones you share.

Trade-offs and pitfalls: a clause that can't actually be measured with tools you already have, or can build cheaply, is worse than no clause at all, because it becomes a dispute later about whose subjective read of "it worked" counts. Every clause should name its exact source of truth before signature, not after.

A good KPI (key performance indicator) set for a POC-focused (proof-of-concept-focused) Solutions Architect role mixes leading indicators, which predict success early, with lagging indicators, which confirm the outcome after the fact, so the role isn't graded only on results that take a full quarter to show up.

Proposed KPIs

1. Time-to-first-POC-delivery (leading): time from a scoped customer request to a working proof of concept, measured from the CRM (Customer Relationship Management system, where sales opportunities are tracked) timestamp of "requested" to "delivered." A realistic starting target: most standard-scope POCs delivered within about 10 business days, adjusted once you see the team's actual baseline.
2. POC-to-pilot conversion rate (lagging): the percentage of delivered POCs that convert into a paid pilot or signed deal within the quarter, measured from CRM opportunity stages. Target: a meaningful improvement over the team's trailing baseline, agreed with your manager once you've seen that baseline.
3. Technical win rate on competitive evaluations (lagging): the percentage of competitive deals where the customer's technical stakeholders rank your solution ahead of the alternative, measured through post-evaluation debrief notes. Target set per vertical, since win rates vary a lot by market segment.
4. Customer Satisfaction (CSAT) on the POC engagement (leading for renewal and expansion risk): a short post-engagement survey score. Target: sustained at or above the org's baseline satisfaction threshold.
5. Rework or defect rate on handed-off POCs (leading, protects long-term quality): the percentage of POCs requiring significant engineering rework after handoff, measured through engineering ticket tags. Target: trending down quarter over quarter, since this is the guardrail against sacrificing quality for speed.

Worked example

Over a sample quarter, you might target delivering 80% of standard POCs within the 10-business-day window (leading), while tracking that the rework rate on those same POCs doesn't rise as a side effect of moving faster (the guardrail), and only judging the conversion rate and technical win rate at quarter's end once there's enough volume for the numbers to mean something.

Trade-offs and pitfalls

A pure time-to-delivery incentive can push you to rush every POC, which is exactly why it needs to be paired with the rework guardrail. Pure lagging metrics like conversion rate can take a full quarter to show any signal at all, which is why leading indicators matter, they tell you if you're on track well before quarter-end.

Before I join a new team, I want answers in four areas: what I'll be measured on, what data and tooling I'll inherit, how the team actually operates day to day, and what's already on fire. Below are twelve questions: ten across those four areas, plus two on team structure, each with why it matters.

Metrics and KPIs (key performance indicators, the specific numbers used to judge whether the work is succeeding)

1. "What are the two or three metrics you'll actually judge my first six months against?" Aligns my effort with what's measured, rather than what merely looks good.
2. "Is there an existing dashboard or report showing the current baseline for those metrics?" Grounds any target I commit to in reality instead of a guess.
3. "Which of those metrics are actually inside my control, and which can I only influence?" A metric I am judged on but cannot move without three other teams agreeing is a target I should renegotiate now, not at the review.

Data and tooling

4. "What's the primary stack, and where does data quality or reliability break down today?" Surfaces known landmines before I inherit them silently.
5. "Which tools are the actual source of truth versus legacy systems people still half-use?" Avoids wasting early weeks mastering a tool the team is already abandoning.

Process and rhythms

6. "What's the meeting cadence, standups, planning, one-on-ones, and who actually attends?" Sets realistic expectations for calendar load and where decisions get made.
7. "How do decisions get made when the team disagrees, and who has the final call?" Clarifies decision rights (who is actually authorized to decide) before I need that answer under pressure.

Immediate problems

8. "What's the one thing that's been broken or blocked the longest?" Reveals the real priority behind the polished job description.
9. "What did the person previously in this role do well, and where did they struggle?" Sets a realistic bar and flags landmines without me having to rediscover them the hard way.
10. "What has been tried on that problem already, and why did it not stick?" Stops me from proposing in week two the exact fix that failed last year for reasons nobody wrote down.

Team and reporting

11. "Who do I report to day-to-day versus who formally evaluates my performance?" These can differ on matrixed teams (a structure where you have both a functional manager and a separate day-to-day project or product lead, each with real influence over your work), and the gap matters.
12. "How many people are on the team, and how is work currently split among them?" Shapes whether I'm stepping into an ownership role or a support role.

Trade-offs and a closing practice

Ask the hiring manager and a team lead separately where you can; their answers to "what's broken" often diverge, and the gap is informative. Don't ask questions the job posting already answered, and prioritize the ones most likely to change your decision or your first 90 days. A strong habit once you land the role: turn the answers into a short written role-expectations document you both sign off on, so priorities don't quietly drift a month later.