• It's important to know what your goals are.
• It's important to understand why they are your goals.
• It's important to determine which goals are more important than others (goals priority).
• It's important to know which goals are dependent on other goals (goals decomposition and dependency).
• To reach a goal, you must first acquire the tools (knowledge, resources) to get to your objective.

• It's important to know when to drop/abandon goals.

• Sources of inefficiency

  • Repeating the same task without sufficient experience.

• Always try to figure out the most optimal path toward a goal

  • Observe others successful at achieving the goal you want to achieve.
  • Determine the differences between your state and theirs (what they know, what resources are available to them, etc.).
• How to determine when it is not possible to reach a goal at a given moment in time?
  • Not enough time available
  • Too costly
  • Dependencies not resolved/ready

• It's difficult to remember/know the current state of a project
  • Keep notes of the work that has been done, what is left to do
    • Create a to do list first, then proceed from that to do list
    • Update the to do list as you notice things that should be/not be done

Process

• Determine what was worked on last time
• Determine what needs to be worked on now (priorities)
• Establish the current state of the project
  • Look at the state of tasks in the issues tracker
  • Ask others about the status of the project

• Company name
• Product name
• What problem we are trying to solve
• How we are solving it
• Why should you trust if vs our competitors
• List what it can already do
• List what we expect to be able to do
• Link to our bug tracker
• Subscribe to our mailing list
  • Become an alpha tester
  • Early access program

• Email to contact for any question

• A/B testing of the price

• Testimonials

• Full website

  • Packages/Pricing/Plans
  • Feature list

• On signing

  • Send an email to a small survey
    • Establish the price range people would be willing to pay
    • Establish the type of model they'd be willing to accept
    • Check what feature they're the most interested in
    • Check which feature they'd like to see in the future
• Events tracking
  • Seen sections of the landing page/
  • Mouse movement/heatmap/session recording (viewport + mouse position)

TODO

• Define the information you want to collect/know more about

Extracted from articles

• Unique Selling Proposition
• Hero shot
• Benefits of your offering
• Social proof

• Call-To-Action (single conversion goal)

• The headline should inform the user what the product or service is all about

References

• http://unbounce.com/landing-pages/7-elements-of-a-winning-landing-page/
• https://blog.kissmetrics.com/beginners-guide-to-landing-pages/
• https://blog.hubspot.com/marketing/landing-page-examples-list
• http://thelandingpagecourse.com/landing-page-101-intro/
• https://blog.crazyegg.com/2014/10/07/landing-page-essentials/
• https://blog.crazyegg.com/2016/03/18/6-laws-of-landing-page-optimization/
• https://www.codeinwp.com/blog/landing-page-basics-you-should-know/
• https://www.weidert.com/whole_brain_marketing_blog/bid/206472/7-basic-landing-page-guidelines-that-make-or-break-conversions

Principle: a fundamental truth or proposition that serves as the foundation for a system of belief or behavior or for a chain of reasoning.

• Effectiveness over efficiency.
• Avoid spending your time on negative thoughts.
• Do not spend too much time thinking about hypothetical situations.
• Always improve.
• Always adapt.
• Surround yourself with positive people.
• Do not engage in fruitless debates or one-sided confrontations.
• Accept that nothing is perfect.
• Know what you want and don't want.
• Do not delay difficult decisions indefinitely.
• Learn new things everyday.
• Work on fewer things to get them to completion.
• Spend no time complaining.
• Spend time working on interesting things.
• Have people depend on you less and less.
• Work on things that matter.
• Avoid repeating yourself constantly.
• Continuously optimize.
• Have a structured process for everything you do that is written down and updated as it changes.
• Always remain positive.
• Put your time where you get rewarded for the effort.
• Minimize your regret.
• Invert, always invert.
  • Spend less time trying to be brilliant and more time trying to avoid obvious stupidity.
  • https://fs.blog/2013/10/inversion/
• Always write down why.
• Priority, priority, priority.
• Focus on input, not output.
• Copy, transform, combine.
• Use analogies when reasoning about complex ideas.
  • Sometimes equivalents make it easier to reason about a problem when translated into a different domain.
• Prefer action over a perfect decision.
• Always plan, even if you don't end up using the plan.
• Never discourage anyone who continually makes progress no matter how slow.
• Stop starting, start finishing.
• Plan with the most realistic scenario in mind.
• Plan by preventing the worst scenarios from happening.
• Spend your time with happiness generators, stay away from happiness drainers.
• Always limit how much time you spend dwelling on problems and mistakes.

The onboarding process described here is specific to a software engineer joining a tech company. While some/most of the items may still apply to any job where you mainly work from a computer, the assumption will be that you develop software as an individual contributor.

Week 1

• Setup laptop
• Access to slack
• Access to zoom
• Setup calendar reminders
• Initial meeting with buddy
• Access to git central repository
• Installation of development tools/languages
• Request software licenses
• Access to CI/CD
• Find where task management is done
• Find the documentation to build projects
• Connect 1 on 1 with each member of the team
• Meet with manager 1 on 1
• Define a 30-60-90 days plan with manager
• Verify access to various systems (SSO, code repository, insurance company, payroll company, etc.)
• End of week meeting with buddy

Week 2

• Setup and run the one step build process
• Determine how are features/tasks prioritized, who prioritizes features/tasks
• Review the team documentation
• Review team practices/processes documentation (code style, code review, standups, planning, retrospective, demos)
• Review common vocabulary, terminology, glossary documents
• First PR + code review
• Review the career ladder of the position

Week 3

• Review user definition, use cases, requirements
• Read prior team meetings notes

Week 4

• Identify how deployments are done
• Review the team roadmap
• Determine where I can have the biggest impact
• Determine a timeline where I'll have reached my 80/20 at the company
• Determine the maturity of existing projects
• Determine how fast can we iterate on certain aspects given the team/company composition
• Identify the core/principal/staff contributors and their contributions
• Review the architecture of the system
• Review the database architecture
• Learn about "how we got to this point"
• Determine whether the product is a monolith or micro-services
• Identify which (3rd party) tools are used by the team/company
• Determine the portfolio of STARS situations of the team/company
• Determine a rough estimate of the number of people in the different organizations
• Connect 1 on 1 with important collaborator in other teams
• End of first month meeting with buddy
• First month performance review with manager
• Informal 360-degree review with manager and peers on adaptation
• Month 1 job satisfaction review

Week 8

• Team interaction diagram
• Month 2 job satisfaction review

Week 12

• Month 3 job satisfaction review