Day 1: The Fool's Journey
Published: 2023-10-31 11:18:25


> Just as the first card in the Tarot deck signifies, we embark on the Fool's Journey. Everyone hopes to swiftly reach the destination, leading many to search for shortcuts. Yet, the true shortcut lies in not taking detours.


### **1.1 The Impossible Triangle**

In the role of project leaders, it's crucial to understand the "Impossible Triangle": Time, Features, and Manpower.

* **Time:** A central element in project management. Every endeavor comes with a deadline or a strict timeline that must be met. These time constraints often arise from stakeholder expectations. Project managers must set a precise plan, determine the Work Breakdown Structure (WBS), and pinpoint milestones to ensure timely project completion.

* **Feature Complexity:** This dimension covers the scope, features, and intricacies of a project. An increase in project functionality or complexity often results in more time and resources. This surge is due to the demand for additional development, testing, and support. Managers must align with stakeholders on the project's features and complexity to ensure the objectives are met, making necessary trade-offs based on feasibility and resource availability.

* **Manpower:** Human resources are vital for the success of any project. This encompasses the team members, their skill set, expertise, and any additional external resources required. Adequate planning and allocation of manpower are essential to fulfill project needs, including determining team size, identifying skill necessities, and coordinating resources. Insufficient or improper allocation could lead to delays, quality issues, or budget overruns.

In the realm of project management, managers and teams must strike a balance among these three pillars to achieve optimal outcomes. This often involves constant tweaks and decisions to ensure the project meets the criteria of time, functionality, and resources. Effective communication with stakeholders is also essential to align their expectations and requirements and find the equilibrium within the "Impossible Triangle" for project success. Achieving this balance demands meticulous planning, efficient communication, and adaptable management tactics.

Moreover, none of these three factors is universally paramount, but within a specific project, priorities invariably emerge. Given our current project, our human resources are fixed, and we've also predetermined that completion within a week is non-negotiable. Thus, with two sides of the triangle set in stone, our only wiggle room is the complexity of the features.

In product development, the allure of countless features and innovations can be overwhelming. Faced with an endless feature list, tough choices are inevitable. The bridge between aspiration and reality is determined by feasibility and core value.

> List all the features, then slash it in half, and half again. Develop what remains and launch.

Remember, done is better than perfect. When listing all features, first halve the list, retaining only those crucial to the product's core value. Then, scrutinize this condensed list, cutting it in half once more. What you're left with is the truly essential set of features that will allow you to launch your product quickly.

1. **Time is a precious commodity.** Attempting to implement every feature all at once not only drags out the project but might also divert focus from essential features.

2. **Perfection is the enemy of the product.** Striving for perfection can mire the team in endless tweaks, leaving completion ever out of reach.

3. **Rapid feedback is key.** A swift market entry means real-time user feedback, facilitating the necessary iterations and enhancements. This is far more practical than squandering time on chasing perfection.

5. **The landscape and needs evolve.** Over an extended development cycle, both market dynamics and user requirements can shift. Being bogged down with feature buildup might mean missing the market's prime window by the time the product launches.

### 1.2 Product Features and the PRD

> PRD stands for Product Requirements Document. The primary aim of crafting a PRD is to accurately define product functionalities and user experience.

Given our tight seven-day window, many, once they have a rough idea, are chomping at the bit to pen down the initial lines of code. Yet, as the saying goes, "A well-prepared PRD can save countless hours down the line." Many mid-project quandaries arise from ill-defined initial requirements and rules. A well-drafted PRD can offer clear project expectations:

* **Reduce Iterations:** Clear requirements from the outset can cut back on the number of iterations later.

* **Risk Management:** With set requirements and constraints, teams can identify and handle potential risks more effectively.

* **Resource Allocation:** A precise PRD enables better allocation of resources and time by project managers and their teams.

* **Clear Direction:** A PRD ensures the team's alignment on the product's objectives and anticipated functionalities.

* **Guidance Provision:** It offers a clear directive for development, design, and testing teams.

* **Enhanced Communication:** The PRD serves as a tool for communication within the team, ensuring everyone's on the same page regarding product direction.

* **Evaluation & Feedback:** The PRD provides a standard for product assessment, helping teams measure if the end product meets the initial expectations.

Clearly, adopting an iterative approach facilitates a stepwise project progression, and a PRD is the best tool to minimize non-productive iterations.

Here's a simplified PRD demonstration for this project: [Appendix: GPT-onion Product PRD](https://walkman42.gitbook.io/best-practice-in-7days/appendix/fu-lu-1.gptonion-chan-pin-prd)

Armed with a comprehensive feature list, we can then prioritize based on the next stages of practical implementation. While I'm currently uncertain about the completion percentage over the seven days, we can at least establish a hierarchy, focusing first on the most crucial aspects.

#### **1.2.1 User Roles**

> To see what is often unseen.

The crafting of the "User Roles" section is an area frequently overlooked by rookie product managers who haven't systematically executed projects before.

Reasons why user roles tend to be overlooked:

* **Assumptions About the User:** Teams might already have their own assumptions about the user, thinking they know what users want, hence bypassing the step to define user roles.
* **Overemphasis on Technology:** Tech-driven teams might overly focus on technical implementation and features, sidelining the actual needs of users.
* **Time and Resource Constraints:** In a rapid development setting, teams might feel they lack the time to delve into and define user roles.
* **Lack of User Research:** Not conducting ample user research, or not viewing it as a priority, could lead to sidelining user roles.
* **Document Complexity:** Writing out user roles could compound the complexity of the PRD. Some teams might opt to simplify the PRD to hasten the development process.

So, what are the user roles for GPT-Onion?

* **Visitor**:
  * Browse the public AI prompt library.
  * Engage with the dialogue interface using prompts as a guest.
    * Get prompted to log in when attempting to chat.
  * View community-curated collections (Collections).
  * Access educational and tutorial resources.
* **Registered User**:
  * Create and manage personal accounts.
  * Create, edit, and delete their own AI prompts.
  * Create, edit, and delete their own curated collections.
  * Interact with community members (e.g., commenting and rating).
* **Community Admin**:
  * Manage community content and users.
  * Provide user support and guidance.
  * Analyze platform usage and feedback to enhance platform features.

Once we have the user roles clearly listed, some readers might have an epiphany, "Oh, how did I forget about the admin?"

This underscores the importance of determining roles before pondering over features. We are prone to subjectively putting ourselves in the shoes of a registered user when mulling over problems since that represents the majority's need status and core demands.

However, when the role of a visitor is taken into account, some intricate details of the feature process become explicitly articulated. This can minimize code revisions for developers later on. The tighter the timeframe, the more time this saves.

> Development should not only account for the usual logic but also make allowances for atypical logic.

Recall our initial saying, "The real shortcut is not taking detours."

Thus, the necessity of penning user roles is evident:

1. **Specify Target Users:** Determining the product's target users lays the foundation for product design and development. This aids the team in concentrating efforts on delivering the most valuable features to specific user groups.
2. **Amplify Resonance:** Grasping user roles can assist the team in resonating better with users, understanding their pain points, and requirements.
3. **Guide Design Choices:** User roles proffer a framework for designers, aiding them in factoring user needs and expectations when designing interfaces and interactions.
4. **Facilitate Efficient Feature Decision-making:** Knowing the user roles and their tasks can guide the team in discerning which features are imperative and which are secondary.