docs: Add introduction doc landing page

Add a brief introduction to the template in README.md.

Signed-off-by: Jan Tore Guggedal <jantore.guggedal@nordicsemi.no>

Author: jtguggedal

README.md

@@ -7,11 +7,25 @@
 [![Target_tests](https://github.com/nrfconnect/Asset-Tracker-Template/actions/workflows/build-and-target-test.yml/badge.svg?event=schedule)](https://github.com/nrfconnect/Asset-Tracker-Template/actions/workflows/build-and-target-test.yml?query=branch%3Amain+event%3Aschedule)
 [![Power Consumption Badge](https://img.shields.io/endpoint?url=https://nrfconnect.github.io/Asset-Tracker-Template/power_badge.json)](https://nrfconnect.github.io/Asset-Tracker-Template/power_measurements_plot.html)
 
-The Asset Tracker Template is under development.
-
 ## Overview
 
-Template for Cellular IoT development on Nordic Semiconductor nRF91 Series LTE devices
+The Asset Tracker Template implements a modular application framework for nRF91-based IoT devices.
+The application is built on nRF Connect SDK and uses a combination of state machines and message-based inter-module communication.
+It is intended to be a framework for developing asset tracking applications, but can be customized for other use cases as well.
+We have not targeted a specific use-case with this template, but rather a set of features that are common in asset tracking applications, and left it up to the user to decide how to use, modify, or extend the template to fit their needs.
+The ``main.c`` file contains the main module of the application, where the business logic and control over the other modules is implemented, and is a good starting point for understanding how the application works.
+This is also the naural place to start when customizing the application for a specific use-case.
+
+The template is open-source for a reason, and we encourage users to contribute back to the project with improvements, bug fixes, or new features.
+
+## Key concepts
+
+* **Modular design**: The application is divided into modules, each responsible for a specific feature or functionality.
+* **State machines**: Each module, where applicable, has its own state machine, which defines the behavior of the module. The state machines are implemented using Zephyr's [State Machine Framework](https://docs.nordicsemi.com/bundle/ncs-3.0.0-preview1/page/zephyr/services/smf/index.html).
+* **Message-based communication**: Modules communicate with each other by sending messages using [zbus](https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/services/zbus/index.html), a message bus library for Zephyr.
+* **Configuration options**: The application can be configured using Kconfig options to enable or disable features, set parameters, and more.
+* **Designed for low-power operation**: The application is designed to be power-efficient, with features like LTE Power Saving Mode (PSM) enabled by default.
+
 
 ## Table of Contents